To Beat all the OWP Blues
Hope the below information and examples will beat all the OWP blues.
SAP GRC Process Control provides the functionality Offline Workflow Process (OWP) to deliver workflow tasks for Assessment, Tests and Disclosure Survey offline and use email instead of accessing the portal inbox. Offline workflow Process can be divided in two parts:
1> Outbound Workflow Process
2> Inbound Workflow Process
To facilitate enabling of this functionality, there are IMG activities under the path Governance, Risk and Compliance -> Process Control ->Offline Workflow Process
1) Outbound Workflow Process
This mainly constitutes of picking up of new workflow item ids for process control related tasks, check whether this workflow item corresponds to one of the supported scenarios. Next get the agents who should receive the email, then build the pdf form and send.
For Outbound process to work you need to do the following two configurations:
a) Configure OWP Business Scenarios In this activity, you configure the view of GRFNV_OWPBSC. This is the table that is used for controlling the layout and logic of the Adobe form. There are 18 default scenarios delivered with the product. You can also customize your own scenario. The following scenarios are not supported:
- Ad hoc issue
- Remediation with CAPA plan
- Manual Control Performance
Rest of the information can be found in the documentation for IMG activity itself or the documentation provided with the note 1633989 - Technical user guide for OWP
b) Set Up Job to Deliver PDF through E-mail
This IMG activity is for setting up the background job to deliver PDF forms through e-mail when there are new tasks pending.
The other two prerequisites for the outbound workflow process to work are:
> Adobe Document Services Adobe Document Services Configuration must be completed for the backend system. For more information about configuring Adobe Document Services, see SAP Note 894009. Run the test programs FP_TEST_00, FP_PDF_TEST_00, and FP_TEST_IA_01 to check whether the configuration has been completed correctly. For more information about troubleshooting forms processing, see SAP Note 944221.
> SMTP Configuration Guide Refer to SAP NetWeaver help : http://help.sap.com/saphelp_nw70ehp1/helpdata/en/af/73563c1e734f0fe10000000a114084/frameset.htm
Troubleshooting of outbound workflow process To test the outbound workflow process there is a standard program ‘GRFN_OWP_SENDER_TEST’ which you can run by supplying the work item id for which you are expecting the outbound to work but it isn’t. After running the same you can use the transactions SOADM /SCOT to check for the outbound send requests as shown in Pic below.
If you can see the e-mail sent for the workitem id, no further checking for outbound is required. Incase you do not see the e-mail sent then you need to check the system logs in transaction SLG1 with Object ‘GRFN’ and subobject ‘OWP’ as in pic below.
Another place which is of significance with respect to outbound e-mail processing is the table ‘GRFNOWPSIKITM’. This table contains the sick workitem stack. The table contains the workitems which was picked by the job that runs the program ‘GRFN_OWP_SENDER’ but not processed successfully. Mainly this happens when the workitem has not been assigned to any agent or the agent does not have a email address maintained. There can be other reasons also. The workitems are automatically deleted from table ‘GRFNOWPSIKITM’, if the workitem can now be delivered successfully or the workitem is set to completed/deleted/cancelled. Relevant Notes: 1754395 and 1947227.
2) Inbound Workflow Process
This process comprises of processing of the OWP related pdf forms that is received by the system.If this process is successful, then current workflow stage is completed and the processing goes to the next level. Below is the configuration which needs to be in place for the inbound process to work.
a) Configure E-mail Inbound Process This configuration is done for handling the inbound e-mail and calling of proper exit ‘CL_GRFN_OWP_DELIVER’ upon receiving.
1. Insert a new row.
2. Enter the Communication Type: Internet Mail.
3. Enter an e-mail address in the Recipient Address column. Note: The left side of the @ symbol is for a username that exists in your system and can act as sender of task. The right side of the @ symbol is for the domain which is defined in the Customizing activity Handle E-mail Configuration (transaction SCOT: domain field).
4. Enter the Document Class: *. Note: The wildcard (*) allows all documents to be sent to the recipient. If you want to limit it to certain types of documents, that can be entered here.
5. Enter the Exit Name: CL_GRFN_OWP_DELIVER.
6. Enter the Call Sequence.
7. Save the changes.
Incase of inbound workflow process not working, you need to check the following in order
I. Email sent is received by the system. For this you need to check the inbound send request in one of these transactions SOIN, SOADM or SCOT. If E-mail is not received you need check the SMTP Configuration. No system logs for OWP will be created until this point.
II. Email received but exit is not called. This means that configuration done in transaction SO50 is not proper. If Email is received and no system logs for OWP is created then this means exit is not called. Check the settings as described in 2(a).
Especially the recipient address maintained. The full server e-mail address which the technical recipient should be added here. Here are some steps to make sure that the right technical recipient is maintained here.
i) T-code = SOIN, this displays the inbound messages as they hit the server. • If the message tracing is off, turn it on. • At the top of the screen: Utilities > Trace Settings
ii) Send new test message to the system
iii) Refresh the SOIN screen. When the message arrives select the message, and press the icon that looks like a scroll (Display Trace), then double click on the Trace ID.
Check the call sequence. The number specified defines the sequence in which the exits are called if more than one suitable exit is found for a send order. Subsequent exits are then only called if the exit that was last executed did not execute the delivery. The sequence of exit class ‘cl_alert_confirm_by_mail’ is of importance as it checks if the incoming sent message is an alert and exits if it is not and further processing does not happen. Hence, it should come after the OWP exit in sequence.
b) Exit is called and SLG1 logs are created, even then if inbound workflow process was not successful. Then check for the following common issues that happen.
- Error is ‘Failed to determine set back user workitem XXXXX ‘. This error happens when the e-mail address which has sent the inbound message is not same as e-mail address of the agent derived for the workitem. This can happen due to multiple reasons:
> Multiple agents receive the outbound e-mails for one particular workitem and it can happen that before someone responds via e-mail, another user has already reserved the workitem from the Workinbox. In this case the response via e-mail will not be considered and the sender will get a reply from the system regarding the same.
> The E-mail address of the sender and e-mail address maintained for agent does not match.
- Error ‘Error occurred when trigger sub job for workitem 8’ happens when the user who processes the inbound exit program does have proper authorization. The user should have the profiles SAP_ALL, SAP_NEW and S_A.SCON.
- In case you get the following error, you need to check your Adobe Document Services Configuration.
Will try to add more such scenarios as an when I come across.