Requested Data Shop Order

The requested data shop order list contains all data shop orders which are not yet approved. After approval, they appear in the executed or scheduled tasks list. If the order is rejected instead, the execution will not start.

Concepts and more information

Using the Data Shop

Permissions

Requested Executions have specific permissions to manage user access. The table below displays the available permissions and their purposes.

For more details about the concept of XDMs permission management refer to Permission Management.

Permission	Description
ADMINISTRATION	Specifies that the grantee can grant and revoke permissions to and from other users. A user that creates an object automatically receives the `ADMINISTRATION` permission on that object.
DELETE	Specifies that the grantee can delete objects of the selected types.
READ	Specifies that the grantee has read permission on the object. The grantee is able to see the object in lists and can see all of the object’s details, such as rules or access permissions. In addition, the grantee can reference this object. For example, a user who has `READ` permission on a credential object can refer to this credential object when creating a new database connection.

Permission

Description

ADMINISTRATION

Specifies that the grantee can grant and revoke permissions to and from other users.

A user that creates an object automatically receives the ADMINISTRATION permission on that object.

DELETE

Specifies that the grantee can delete objects of the selected types.

READ

Specifies that the grantee has read permission on the object. The grantee is able to see the object in lists and can see all of the object’s details, such as rules or access permissions.

In addition, the grantee can reference this object. For example, a user who has READ permission on a credential object can refer to this credential object when creating a new database connection.

Properties

The table below documents the available properties for requested executions. The 'name' column displays the property name as it can be used in Groovy and Java Scripts.

Name	Type	Default	Description
Data shop dataRequestForm	DataRequestForm	n/a	Specifies the data shop from which the order was placed.
Exit message exitMessage	String	n/a	If the order was rejected, the reason for the rejection is displayed here, otherwise the field is empty. Every rejected order needs a reason for rejection.
Ordered by orderedBy	PermissionRecipient	n/a	The user who ordered the data shop.
Order time orderTime	Timestamp	now	The time when the order was placed.
Start time startTime	Timestamp	now	If the requester has specified a timestamp in the request order dialog, the execution will be scheduled for that time, after it has been approved. If the start time is not set, the execution will start immediately after the request was approved.
Status status	QueuedExecutionStatus	n/a	Shows the current status of the execution. The status is displayed as colored circle with a description when holding the mouse cursor over the circle. Displayed values are: Rejected The request was refused by a user and will not be executed. The reason for the rejection can be found in the reason field. Waiting for approval The request for execution must be approved by a user with the necessary permissions. Upon approval of the request, execution begins.

Name

Type

Default

Description

Data shop

dataRequestForm

DataRequestForm

n/a

Specifies the data shop from which the order was placed.

Exit message

exitMessage

String

n/a

If the order was rejected, the reason for the rejection is displayed here, otherwise the field is empty. Every rejected order needs a reason for rejection.

Ordered by

orderedBy

PermissionRecipient

n/a

The user who ordered the data shop.

Order time

orderTime

Timestamp

now

The time when the order was placed.

Start time

startTime

Timestamp

now

If the requester has specified a timestamp in the request order dialog, the execution will be scheduled for that time, after it has been approved. If the start time is not set, the execution will start immediately after the request was approved.

Status

status

QueuedExecutionStatus

n/a

Shows the current status of the execution. The status is displayed as colored circle with a description when holding the mouse cursor over the circle. Displayed values are:

Rejected: The request was refused by a user and will not be executed. The reason for the rejection can be found in the reason field.
Waiting for approval: The request for execution must be approved by a user with the necessary permissions. Upon approval of the request, execution begins.

Actions

The available actions are described below. Some actions apply to the list, while others are specific to selected requested executions.

List Actions

The following actions are available on the requested executions list. If the action is disabled a tooltip will provide the exact reason for the deactivation. The required permissions are described in detail for each action.

Bulk Create Permission
Bulk Delete
Export

Create a new permission on the selected objects. Shows in the result list whether the permission could be granted on the respective object. Only these permissions can be granted that are existing on the underlying object.

A permission in the result list can have three different states, these are:

CREATED: The permission successfully granted on the object.
MERGED: The granted permission already exists on the object and merged with the new permission.
SKIPPED: The permission could not be granted, because of missing administration permission on the object.

The following permissions are required on the list:

ADMINISTRATION
READ

Delete the selected objects.

The following options are available:

Cascade: Recursively delete depending objects.

When using cascade, dependent objects are deleted first also with cascade enabled. Thus, a cascade deletion is a recursive function that deeply searches for dependent objects and deletes them first. There is only a confirmation for the first object. The dependent objects are deleted without confirmation but only when the user has the DELETE permission.

This feature is only available in development mode. More information about development mode can be found in the chapter User Settings. It should be used with caution.

An object in the result list can have two different states, these are:

DELETED: The object could be deleted.
NOT_DELETED: The object could be not deleted. This may be because the executing person does not have a delete permission on the object or the object is still referenced by others. A detailed reason can be determined with the help of the error message. If the object is still in use, these objects are also displayed.

The following permissions are required on the list:

DELETE
READ

This action allows to export XDM objects in different formats in order to import them via export or CasC in another environment.

Refer to configuration of export for more information.

Related and dependent objects can optionally be included in the export. The export dialog has the following options:

Include dependent objects: Dependent objects only belong to the exported object like rules and tasks.
Include permissions: Permissions of each exported object, only when the object supports permissions. Some objects like rules don’t have permissions.
Include referenced objects: Referenced objects exist by their own and are used in the exported object like connections and environments.
Include objects that depend on referenced objects: Also include the dependent objects of the referenced objects. E.g. the rules of a modification set or the rules in an application model version.
Include implicit created objects: Implicit created objects are tasks or workflows which were automatically created for execution. These objects won’t be exported by default, but can be included by setting this flag. When exporting implicit objects, make sure that the Include dependent objects flag is also enabled.

Objects on which the user does not have READ permission are not exported. This includes dependent and referenced objects. However, the reference to an object will be exported.

For example a connection object would refer to the credential, even if the user does not have READ permission on the credential. The definition of the credential object itself will not be part of the export file. This can lead to issues during the import, because the connection cannot be created without an existing credential.

The following permissions are required on the list:

READ

Object Actions

The following actions are available on specific requested executions. In order to execute the action, the user must possess the necessary permissions for the object. The permissions required for each action are described individually. If the user does not have these permissions, the action will be disabled and the tooltip will provide the exact reason for the deactivation.

Approve Request
Delete
Edit
Event List
Reject Request

This action approves a pending data shop request. A user needs the EXECUTE privilege on the data shop to approve a data shop request. The data shop execution will be started directly after it has been approved. The execution can be found in the section Executed Tasks. However, if the data shop request has been scheduled for a future execution, the data shop execution will be shown in the Scheduled Tasks section.