Performing Further Settings

Business workflow tasks can be customized in the following ways.

Customizing task decision options

The decision options for a business workflow task can be customized as follows:

• Add or hide a decision option.

• Change the label of a decision option.

• Define the nature of a decision option (positive or negative).

• Make comments mandatory for a decision option.

Follow the steps below in the back-end system where you maintain your workflow template for customizing the Task Decisions options. Create a decision with decision options:

1. In Customizing for ABAP Platform, choose Gateway Service Enablement →Content→Workflow Settings→Maintain Task Names and Decision Options .

   

2. Fill in the Step Name table as described below and save your entries:

   • Workflow ID: Enter the ID of your workflow template.

   • Step ID: Enter the task step from your workflow template.

     The Workflow ID and Step ID can be copied from the Workflow Builder (SWDD).

   • Icon MIME Repository Path: Leave this field blank.

     

3. Select the entry in the Step Name table and choose Decision Keys in the navigation panel. Add and define your decision options in the Decision Keys table as described below and save your entries. The following are further explanations:

   • Key: Enter the decision key.

     Decision keys are numeric and sequential and correspond to the position of decision options in the Workflow Builder. Enter the first decision option with key 1, the second decision option with key 2, and so on.

   • Icon Mime Repository Path: Leave this field blank.

   • Decision Text: Define the label of the decision option.

     This name is displayed on the application screen as a button label. The proposed length of the decision text is maximum 14 characters. Decision texts longer than 14 characters will not fit to the device screen.

   • Comment On: If you want to make it mandatory for the user to add a comment when executing a decision, select this checkbox.

   • Nature: Here you have the following options:

     • Select POSITIVE  for the approve type decision option.

       The decision option is displayed either as a green pushbutton or in a grey pop-up (depending on the space available) on the detail screen of the application.

     • Select NEGATIVE  for the reject type decision option.

       The decision option is displayed either as a red pushbutton or in a gray popover (depending on the space available) on the detail screen of the application.

     • Leave the Multiple Decision Options field empty.

       The decision options are displayed either as gray pushbuttons or in a gray popover (depending on the space available) on the detail screen of the application.

Customizing task display name

Follow the steps below in the back-end system where you maintain your workflow template for customizing the task decisions options:

1. In Customizing for ABAP Platform, choose Gateway Service Enablement→Content→Workflow Settings→Maintain Task Names and Decision Options.

2. Fill in the Step Name  table as described below and save your entries.

   In addition to the Workflow ID and Step ID, a Step Description can be entered. This step description would be displayed as the Task Definition Name when the end user tries to filter the task based on task type.

Since the manager’s role has been assigned to both system aliases, ERP_EMEA and ERP_APJ, the manager will retrieve results with the new key field SAP__ORIGIN where SAP__Origin will have the value ERP_EMEA as well as ERP_APJ.

Since the employee EMEA’s role has only been assigned to alias ERP_EMEA, the employee will only retrieve results with the new key field SAP__ORIGIN where SAP__Origin will have the name ERP_EMEA.

You can flag Read Feed Requests of a Service in Multiple Origin Composition (MOC) mode to make the service error-tolerant.

If a feed of a service is called in MOC mode, the service composes the data from all back-end systems assigned to it. More precisely, all system aliases assigned for the current user and service are identified. Then the back-end system of each of these system aliases is called, reading the data from each system. Finally, the results of each back-end system are composed into one feed that is returned to the client.

To call a service in MOC mode, segment parameter mo is added to the service name of the request URL. For example: /sap/opu/odata/IWPGW/TASKPROCESSING;mo;v=2/TaskCollection.

The default error behavior is not error-tolerant. If the data retrieval from any of the back-end systems causes an error, the READ feed request returns that error. If a service is marked to be error-tolerant, this behavior changes:

• An error is returned only if the data retrieval from all back-end systems causes an error. Otherwise, if only some of the back-end systems cause an error, a feed is returned to the client.

• The data retrieved successfully from some of the back-end systems is composed into that feed.

• The data missing from those back-end systems that caused an error can be requested again. For that, an OData skiptoken is added to that feed.

For example: Source Code<link rel="next" href=" TaskCollection?$skiptoken=MISSING_DATA_FROM__1_2" />

An IMG activity to customize the error tolerance is available:

1. In the SAP Gateway system, open the SAP Reference IMG in transaction SPRO  and navigate to ABAP Platform→SAP Gateway→OData Channel→Composition→Set Error Tolerance for OData Services for MOC.

2. Create an entry for the Taskprocessing service.