Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

When integrating SAP and OneList there are two basic options:

  1. Surfacing standard SAP Workflow tasks in OneList. Executing the actions in OneList then updates the Workflow or underlying SAP / business object.

  2. Surfacing actions from a FAB Workflow in OneList. Executing the actions in OneList then updates the FAB Form workflow status.

Your company may use both options, or only one - either way, you will have to do some common configuration / setup for the processes to work. For example, the background job that needs to run to manage the communication between SAP and OneList will have to be set up in the system / client where the workflows are running.

...

Define a Scheduler background job via SM36 with the following values:
Note: Do this in the client where you are executing your development, testing (Dev Unit Test or QAS), and in the live/productive client at go-live.

Step 1

Enter the Job Name , for example ONELIST_JOBS_SCHEDULER

Step 2

Enter the Job Class - B or C (Medium / Low priority)

Step 3

Press the Step button

Step 4

Enter the ABAP Program Name - /IQX/ONELIST_JOBS

Step 5

Enter the User - e.g. OL_ADMIN 

  1. A service user account must be created to run these background jobs, similar to WF-BATCH. This user can be allocated any name (like OL_ADMIN above) to fit in with your organisation's policies / standards. 

  2. We recommend that this user should be classified as a 'System' user in SU01 (not 'Dialog'):

  3. We recommend that, like WF-BATCH, the service account must have broad authorisations (to be able to start background jobs, call programs, execute the methods in the Adapter framework, etc.). We therefore recommend SAP_ALL be allocated to this user. If that is not possible, then the user must be given at least the following roles in the table below, see Roles and Authorizations for Background Processing.

Press the Save button

Step 6

Press the Start conditions button

Press the Date/Time button and enter the scheduled start date and time

Press the Period Values button and choose Other period from the options

Enter 1 in the Minute(s) field

Image Modified

Press the Save button to complete the setup

Once the OneList Scheduler background job has been created, it will automatically schedule the OneList Adapter jobs defined in the 'OneList Job configuration' entries, discussed below (or the /IQX/OL_JOB_DEF maintenance table further down, for older versions).

Roles and Authorizations for Background Processing

This role contains non-critical basis authorizations for all users, including job creation and job release.

Authorization Object

Fields

Value

Description

S_BTCH_NAM

BTCUNAME

*

Authorized user when scheduling

S_BTCH_ADM

BTCADMIN

Y

User is batch administrator

The value "Y" of BTCADMIN enables all operations for any jobs across clients.

For more information, you may refer to the SAP Help https://help.sap.com/doc/saphelp_snc70/7.0/en-US/4e/c48f2468ac35fde10000000a42189e/content.htm?no_cache=true and SAP Note 101146.

...

  • OneList v6 Adapter framework is installed on your SAP Backend system 

  • SAP Workflow already completely built and functional. You will need to know the decision task number (TSxxxxxxxx) so that you can configure the Adapter to read the task information.

SAP Development tasks

  1. Create a custom implementation class (this will become your custom SAP OneList Adapter) based on the IQX Adapter base class:

    1. Use the Class Builder in SAP (t-code SE24) to open the class /IQX/CL_SAP_WL_ADPT.

    2. From the menu bar, select Edit → Create Subclass.

    3. Enter the name of the subclass in the Class field.

      • e.g. ZCL_OL_PO_ADAPTER

    4. Enter a short description in the Description field.

      • e.g. Purchase Order adapter for OneList

    5. Choose Save.

    6. Enter the Package and choose Save again.

  2. Redefine the following inherited methods (click on the method for the implementation example):

    1. EXECUTE_ACTION - this method is called by the Adapter base class/es when the Adapter receives information from OneList. 

    2. GET_ATTCHMENT_CONTENT - this method is called by the Adapter base class/es methods during the sync process (sending tasks to OneList)

    3. GET_OBJECT_DETAILS - this method is called by the Adapter base class/es methods during the sync process (sending tasks to OneList)

  3. Create additional 'helper' methods (called by GET_OBJECT_DETAILS) to retrieve the correct PO information, as well as set up the Action buttons in OneList (this will vary from scenario to scenario - in our example, we are using a Purchase Order. This could be for a Parked Document, Purchase Requisition, Work Order or any other SAP Workflow):

    1. GET_PO_DETAIL

    2. GET_PO_ACTION

  4. Check, Save and Activate the implementation class.

OneList SAP Adapter framework configuration

Maintain the OneList configuration tables via transaction /IQX/OL_CONFIG.
Note 1: If the above-mentioned transaction does not exist, then follow the instructions for the previous version below.
Note 2: Use the configuration / development development client, and transport this configuration to subsequent systems like QA and the Productive system. If you have a development Unit Test client, use SCC1 to copy the config from the configuration client.
Note that there is a sequence to be followed, as per the tree structure, shown below:

...

All entries should be marked as 'active' under normal circumstances. The OneList Adapter will dynamically determine the correct URL and API key based on the system that it is running in. Only in unusual situations will the endpoint be marked as inactive, but then the Adapter will not be able to call the OneList instance in the relevant system.

There is a transaction (/IQX/OL_ENDPOINT) that can be run in the 'active' clients (Unit Test, QA and PRD) to maintain these values directly in the active/target system. This should only be used when emergency maintenance needs to be performed (DOS attack, etc.). The changed values should be copied back into the configuration client and added to a new transport.

In the transaction /IQX/OL_ENDPOINT there is a 'Connection Test' option to check for the correctness of the URL and API key. This can be executed in each system:
 or, for example, 

...

  • Next, add an entry for the SAP Workflow process you want to integrate between SAP and OneList.  If you are integrating OneList with an SAP Workflow, you will need to know the Standard Task ID (use the Workflow Builder (SWDD) or transaction PFTS to get this information) that contains the processing steps - in the example below, it is called "SAP WF Process", linking to Workflow task TSxxxxxxxx.

When you add an entry, you will have to specify the following:

...


Then double-click the 'OneList Job configuration' entry in the tree structure. Configuring this step allows the Adapter framework to communicate with the OneList instance, specifically for user integration. IQX has provided a standard user integration Adapter class (/IQX/CL_OL_SYNC_USERS), but in rare circumstances your organisation may need to alter the behaviour of this class. In that case, you will have to create a subclass of this class (see step 1 above, under SAP Development tasks) and override the relevant methods to suit your needs. In that case, instead of /IQX/CL_OL_SYNC_USERS, use the name of your subclass in the below configuration steps. 

You will need to define entries for the SYNC_USER_REQUEST and SYNC_USER_REQUEST_DELTA OneList User Integration APIs/Actions. For each entry, specify:

...


Now highlight the process integration point for which you want to configure the background jobs ("SAP WF Process" in this example). Remember that there can be multiple processes integrated with OneList - these steps need to be repeated for every process:

...

Delegation Profiles that should be synchronized to OneList can be configured in transaction /IQX/OL_CONFIG.

...

Key

Value

Workflow Type

WF - Workflow

Substitution Profile

Defines the Substitution Profile maintained in SPRO that will be used by OneList.

Active

Flag that sets the Delegation Profile as active when ticked or inactive when unticked.

OneList Global Settings

OneList Global Settings can be configured in transaction /IQX/OL_CONFIG.

...

Key

Value

EMAIL_APPR_ENABLED

Flag that sets the email approval enabled if the value “X” or disabled if left blank.

EMAIL_MAX_AGE_DAYS

Defines the maximum age of the email.

EMAIL_MAX_FILESIZE

Defines the maximum size of the email.

EMAIL_SOURCE

Possible values:

  • UM - Email is retrieved from User Master

  • HR - Email is retrieved from HR

  • UM-HR - Default option if no setting is defined. Email is initially retrieved from the User Master. If the User Master is empty, the email is retrieved from HR.

  • HR-UM - Email is initially retrieved from the HR. If the HR is empty, the email is retrieved from User Master.

FAB Workflow integration with OneList (Optional)

Info

Not everyone will integrate FAB Workflows with OneList. If you are using only standard SAP Workflows, then skip this section.

SAP Development tasks

  1. Create a FAB Form with a Workflow (in this example, we will refer to a FAB app called IQX_FAB_APP).

OneList FAB Adapter framework configuration

Maintain the OneList configuration tables via transaction /IQX/OL_CONFIG.
Note 1: Parts of this section may have been done already if you also use standard SAP Workflow with OneList.
Note 2: If the above-mentioned transaction does not exist, then follow the instructions for the previous version below.
Note 3: Use the configuration / development development client, and transport this configuration to subsequent systems like QA and the Productive system. If you have a development Unit Test client, use SCC1 to copy the config from the configuration client.

...

All entries should be marked as 'active' under normal circumstances. The OneList Adapter will dynamically determine the correct URL and API key based on the system that it is running in. Only in unusual situations will the endpoint be marked as inactive, but then the Adapter will not be able to call the OneList instance in the relevant system.

There is a transaction (/IQX/OL_ENDPOINT) that can be run in the 'active' clients (Unit Test, QA and PRD) to maintain these values directly in the active/target system. This should only be used when emergency maintenance needs to be performed (DOS attack, etc.). The changed values should be copied back into the configuration client and added to a new transport.

In the transaction /IQX/OL_ENDPOINT there is a 'Connection Test' option to check for the correctness of the URL and API key. This can be executed in each system:
 or, for example, 

When generating and saving API keys for S4 Hana systems, please note that if the API key starts with special characters (e.g., exclamation mark "!"), the API key value will not be saved. This behavior was observed in our client Transport for NSW's S4H system.

OneList Integration configuration

Note that you will (only once) have to configure a User integration entry. You may end up with multiple processes integrating with OneList, each of which will require their own entry here (and follow-on entries - see below). It does not matter how many processes you integrate with OneList, you will only need to do this step once - the processes all share the user integration. Add an entry to synchronise the SAP users with OneList, as follows (and note that the Task ID and the Fab Layout form entries remain empty): 

...


Then double-click the 'OneList Job configuration' entry in the tree structure. Configuring this step allows the Adapter framework to communicate with the OneList instance, specifically for user integration. IQX has provided a standard user integration Adapter class (/IQX/CL_OL_SYNC_USERS), but in rare circumstances your organisation may need to alter the behaviour of this class. In that case, you will have to create a subclass of this class (see step 1 above, under SAP Development tasks) and override the relevant methods to suit your needs. In that case, instead of /IQX/CL_OL_SYNC_USERS, use the name of your subclass in the below configuration steps. 

You will need to define entries for the SYNC_USER_REQUEST and SYNC_USER_REQUEST_DELTA OneList User Integration APIs/Actions. For each entry, specify:

...


Now highlight the process integration point for which you want to configure the background jobs ("FAB_APP" in this example). Remember that there can be multiple processes integrated with OneList - these steps need to be repeated for every process:

...


Then double-click the 'OneList Job configuration' entry in the tree structure. Configuring this step provides a link between the your form, the IQX FAB Adapter class (/IQX/CL_FAB_ADPT) and the IQX OneList SAP Adapter framework.  For each entry defined here, the Adapter framework will create a background job at the specified frequency, thereby pushing / pulling data to and from OneList. You will need to define entries for the following 4 OneList Integration APIs/Actions:

...

/IQX/OL_TASK_DEF - Task Definition

  1. Create a new entry with the following values: 

    • Job Type - The description of the type of task e.g. PO_APPROVAL

    • O.L.Task ID - The workflow task ID for the object you would like to retrieve the worklist items. e.g. TS20000166

    • Project Name - optional

    • Number - Page size (tasks processed in one run)

  2. /IQX/OL_JOB_DEF - Background Job Definition (more info on this - the entries in this table will be used to automatically create background jobs that will run to execute functionality)

    1. Create an entry for user sync

      • SYNC USER

        • Job Type: SYNC_USER

        • Class - /IQX/CL_OL_SYNC_USERS

        • Subcomponent - SYNC_USER_REQUEST

        • Short Description - Synchronize SAP users to OneList

        • Freq in mins - 5|

    2. Create a new entry for each of the following values:

      • SYNC ACTIONS

        • Job Type - Use the job type defined in the previous step e.g. PO_APPROVAL

        • Class - Name of the implementation class created in step 1.c. e.g. ZCL_OL_PO_ADAPTER

        • Subcomponent - SYNC_ACTIONS

        • Short Description - Synchronize adapter task actions to OneList

        • Freq in mins - 2

      • SYNC ATTACHMENTS

        • Job Type - Use the job type defined in the previous step e.g. PO_APPROVAL

        • Class - Name of the implementation class created in step 1.c. e.g. ZCL_OL_PO_ADAPTER

        • Subcomponent - SYNC_ATTACHMENTS

        • Short Description - Synchronize attachments to OneList

        • Freq in mins - 2

      • SYNC CHANGED TASK

        • Job Type - Use the job type defined in the previous step e.g. PO_APPROVAL

        • Class - Name of the implementation class created in step 1.c. e.g. ZCL_OL_PO_ADAPTER

        • Subcomponent - SYNC_CHANGED_TASK

        • Short Description - Synchronize the changed task list to OneList

        • Freq in mins - 2

      • SYNC DELTA TASK LIST

        • Job Type - Use the job type defined in the previous step e.g. PO_APPROVAL

        • Class - Name of the implementation class created in step 1.c. e.g. ZCL_OL_PO_ADAPTER

        • Subcomponent - SYNC_DELTA_TASK_LIST

        • Short Description - Synchronize detailed task list to OneList (delta tasks)

        • Freq in mins - 2

  3. /IQX/OL_ENDPOINT - OneList Service Endpoint

    1. Create a new entry with the following values: 

      • OneList URL - Specify the URL endpoint configured for OneList 

      • OneList Server App Path: /onelistserver/api/DataSync

      • SSL Client Identity: e.g. ANONYM

      • API Key: The unique API key used by the endpoint

      • Active: Checked

Suggested schedule for background jobs:

Sub Component

Frequency

SYNC_ACTIONS

Every 2 minutes

SYNC_ATTACHMENTS

Every 2 minutes

SYNC_DELTA_TASK_LIST

Every 2 minutes

SYNC_CHANGED_TASK_LIST

Every 2 minutes

SYNC_USER

Every 5 minutes

Note: Make sure you return to the step above to complete the creation of the background job.