Expand +



Everything You Need to Know About Offline Forms and SAP Process Control

by Jan Gardiner, Senior Director, GRC Solutions, SAP Labs, LLC and Matt Hartnett, SAP Security and SAP Process Control Consultant

August 28, 2017

SAP Process Control provides a popular alternative to online completion of assessment surveys, tests of effectiveness, and other surveys—SAP Interactive Forms by Adobe. These offline forms are easy to use but can be initially challenging to set up and test. The following article presents an end-to-end guide that will help you configure, deploy, and manage the offline forms.

What if your SAP Process Control 10.1 users could do their evaluations, surveys, issue management, and other tasks without ever having to physically log in to SAP Process Control? In fact, what if users could have an offline form delivered directly to them via email, and all they would need to do is complete the form and submit it, also via email. That’s right—minimal training, easy to do, and no need to learn how to navigate any part of the SAP Process Control system. Of course, it is also useful to work offline whenever network connectivity is uncertain or unavailable.

SAP Interactive Forms by Adobe with SAP Process Control make that a reality, and they are included with your SAP Process Control license. With these offline forms, licensed SAP Process Control users can perform these evaluations:

  • Control design assessment
  • Sub-process design assessment
  • Manual test of effectiveness
  • Continuous control monitoring and automated testing (as of Support Package 14)
  • Indirect entity-level control assessment
  • Indirect entity-level control test of effectiveness
  • Related review and approval, if enabled
  • Related issue and remediation activities

They can also perform these surveys:

  • Disclosure surveys
  • Policy acknowledgments, surveys, and quizzes
  • Ad hoc organization surveys (as of Support Package 13)

These surveys have some targeted functionality that behaves somewhat differently from evaluations, so they are not treated specifically in this article.

No Need to Design Forms

The SAP Interactive Forms by Adobe are provided as part of your SAP Process Control (and/or SAP Risk Management) system. The forms themselves are already set up to use elements of SAP Process Control, so you do not need to design the forms—that is already done. The various assessments in SAP Process Control are based on surveys, which are created in the Survey Library by assembling questions from the Question Library. The Adobe form for these surveys reads the applicable survey information, so there is no need to create the form itself. In fact, if your SAP Process Control system has customer-defined fields that appear on survey forms, they automatically appear at the bottom of the form.

Similarly, manual tests of effectiveness use test plans created in SAP Process Control, and the relevant Adobe forms use that information as well. Also, related customer-defined fields that would appear on a test of effectiveness would also show at the bottom of the form. For that matter, continuous control monitoring and automated testing offline forms are supported with SAP Process Control 10.1 beginning with Support Package 14. They work in a similar manner, this time routing exceptions using the continuous control monitoring rule engine and related scheduler.

Included with the SAP Process Control license, you may make cosmetic-only modifications to the forms if needed. For example, you can add your company logo to the form or use your company colors. Doing anything such as changing the logic of the forms or changing validation would require an Adobe Designer license, but most users today do not find that necessary.

No Need to Individually Route Forms

Given that little or no forms design is needed, how are forms routed to the right people? The forms use workflow logic already within SAP Process Control to determine the correct recipients, and the email addresses come from the SAP system user setup (transaction code SU01). In fact, provided the user has an email address, the evaluations’ work items are routed both to a user’s inbox online in SAP Process Control and to the user’s email address with an attached Adobe form. Of course, keep in mind that with the Adobe forms enabled, most users never log in to SAP Process Control at all, so they only interact with the system via the offline form.

As a result, it may be extremely quick for those companies currently using SAP Process Control to start using SAP Interactive Forms by Adobe. That is, think days, not months, because many of the key dependencies are already handled. If you are already using SAP Process Control, it is likely that:

  • You have already set up users with email addresses
  • You have created your Question Library and your Survey Library
  • You have created and assigned manual test plans
  • If you are using continuous control monitoring or automated testing, you have already set up business rules and assigned them to controls
  • You are already routing workflow online by using the Planner or Automated Scheduler

So, while these forms are quite easy to use and require virtually no design, they are not always straightforward to initially set up. The rest of this article goes into technical details of how to configure, test, and manage them, along with some valuable troubleshooting tips. Do not be discouraged by the length of this article—it was meant to be a fairly comprehensive guide, and you may find that some of the steps are already done in your system. Once the functionality is set up, most find that the forms work with a minimum of administration, and the user community easily becomes comfortable using them.  

For the ease of referring to the offline workflow processing (OWP) as it exists in SAP Process Control (and SAP Risk Management, for that matter), we use the acronym OWP. Similarly, to refer to SAP Interactive Forms by Adobe we use the term Adobe forms.

Inbound Email Configuration for OWP

We assume the following prerequisite steps are completed prior to configuring inbound email processing for OWP:                                                                         

  • The SMTP email server is  configured in the GRC system and can send email. This is part of standard GRC system set up by the Basis team.
  • Adobe Document Services (ADS) is accessible in the SAP landscape
  • A determination has been made whether OWP is in scope for one or multiple clients per GRC system (one client per system is usually sufficient)      

(Note: Each step in this section must be performed in each system or client.)

Step 1. Maintain the profile parameter using transaction code RZ10. The profile parameter of the GRC application server must be adjusted to support inbound email processing. Profile parameter maintenance is typically the responsibility of the Basis team. See SAP Note 455140 for both inbound and outbound email setup. This setting supports different communication protocols for inbound communication. It is used to open a TCP/IP port for receiving inbound email for OWP. The placeholder <xx> in the parameter name in Table 1 is used to sequentially number parameters that can occur multiple times (starting with 0). PROT specifies the protocol and PORT the port number.

Parameter name

Entry format



Table 1
Internet Communication Manager (ICM) parameter

Only one service can occupy a port. If the system will not receive inbound connections, the port can be set to 0 so that no ports are open for the specified protocol. The TIMEOUT option can be used to define a maximum wait time for a response from the email server (in seconds). Example entries in Figure 1 are for a system with one client.

(Note: This example uses standard SMTP ports 250<##>; however, use of nonstandard ports is possible. See SAP Note 546147.)

icm/server_port_0         PROT=HTTP,PORT=8000,TIMEOUT=60,PROCTIMEOUT=60

icm/server_port_1         PROT=SMTP,PORT=25000,TIMEOUT=120,PROCTIMEOUT=120

icm/server_port_2         PROT=HTTPS,PORT=44300,TIMEOUT=60,PROCTIMEOUT=60

Figure 1
Example ICM parameters for a one-client system

The parameter in Table 2 specifies the virtual mail host for receiving inbound email.

Parameter name

Entry format



Table 2
Virtual  mail host parameter

The placeholder <host> describes the name of the host to which the incoming emails are addressed. A * value can be entered if the email will be sent independently of the host being addressed. The placeholder <port> is the port number to which the incoming email is addressed. The example in Figure 2 is for a system with one client. 

is/SMTP/virt_host_0              *:25000;
Figure 2
Example virtual mail host parameter for a one-client system

A system with two clients capable of receiving inbound email could have the profile parameter settings in Figure 3.

icm/server_port_0 = PROT=HTTP,PORT=1080

icm/server_port_1 = PROT=HTTPS,PORT=1443

icm/server_port_2 = PROT=SMTP,PORT=25000,TIMEOUT=180

icm/server_port_3 = PROT=SMTP,PORT=25001,TIMEOUT=180

is/SMTP/virt_host_0 = *:25000;

is/SMTP/virt_host_1 = *:25001;

Figure 3
Example ICM and virtual mail host parameters for a two-client system

Step 2. Create a user for inbound email processing. Use transaction code SU01 to create a user for inbound email processing. A user for inbound email processing is required for each client using this functionality (one per virtual host, per system/client). This ID receives the inbound email with the Adobe form containing the user’s responses. It then creates a background job to post the content of the form to the system. The ID should be type SYSTEM, and it must have appropriate authorization to create and release background jobs.   

Security requirements are minimal. Run an authorization trace with transaction code ST01 or STAUTHTRACE to create a role with the necessary authorization. Name the ID so that you can identify the system (client if necessary) and direction of the email. This information is helpful when troubleshooting errors. The ID in this example shown in Figure 4 is GRD900_IN, which indicates the system, client, and direction of the email.

Figure 4
SU01 user master record for GRD900_IN

Step 3. Assign a client to SAPconnect Service. Transaction code SICF is used to assign a client to SAPconnect Service. For each client that receives and processes inbound email, an SMTP server must be created in which the virtual mail host is assigned. The virtual mail host receives email sent from the corporate email server on behalf of the GRC system. In transaction code SICF, a standard SAP-delivered SMTP server (SAPconnect) should already be available as shown in Figure 5. If multiple clients in the same system are required, additional entries can be created.

Figure 5
SAP-delivered SMTP server (SAPconnect)

Double-click SAPconnect to go to Figure 6. The Host Data tab should be maintained consistently with the profile parameter settings maintained in step 1.

Figure 6
SMTP server Host Data tab

The Logon Data tab shown in Figure 7 should be maintained consistently with the inbound email processing user ID created in step 2.

Figure 7
SMTP server Logon Data tab

The Handler List tab shown in Figure 8 should have a default entry for CL_SMTP_EXT_SAPCONNECT in the first slot and should not require any changes. The Administration tab does not require any changes.

Figure 8
SMTP server Handler List tab

Step 4. Configure SAPconnect (SMTP). Transaction code SCOT is used to configure SAPconnect (SMTP). When the GRC system was originally set up by the Basis team, SAPconnect settings should have been maintained so that it could send email. Therefore, SAPconnect configuration for outbound email processing is beyond the scope of this article. Refer to section 4 of SAP Note 455140 for more information on this step.

Step 5. Define routing rules on the email server. This step is usually coordinated by the Basis team. It is external to GRC and can occur independently of other steps. For GRC systems to receive email, corporate email servers must know how to route email intended for a specific GRC system or client. The destination is defined using Mail eXchanger (MX) records. The MX record is defined in the Domain Name System (DNS), and it specifies the domain and host responsible for accepting email on behalf of a GRC system or client. When the corporate email server receives a GRC-bound email, it searches the DNS for the MX record that determines where to route the email. Tables 3 and 4 show example MX records.







Table 3
MX record for a one-client GRC system










Table 4
MX record for a two-client GRC system

Step 6. Define exit rules for inbound processing. To define exit rules for inbound processing use transaction code SO50. Inbound email processing for OWP is performed by the class CL_GRFN_OWP_DELIVER. To define the value for the Recipient Address field, combine the ID created in step 2 with the domain for the MX records created in the previous step. This must be done in each GRC system or client. When the Adobe form is sent to the end user, the recipient address is listed as the sender of the email, so when the user submits the form back to the GRC system, it’s automatically sent to the inbound email processing ID as defined in the Recipient Address field shown in Figure 9.

Figure 9
Exit rule definition for Inbound email processing

Step 7. Test the inbound email configuration. Send a test email to the inbound email processing ID to ensure it is successfully received by the system. Execute transaction code SOIN. If the email was properly routed to and received by the GRC system, it will be  listed, as shown in Figure 10.

Figure 10
Inbound email list

Ensure ADS Is Accessible

ADS is required to generate Adobe forms, so it must be accessible in the SAP landscape. The ADS package is installed on an SAP Java instance and it is accessed from GRC via a Remote Function Call (RFC) connection.  

Step 1. Set up ADS. ADS setup is a prerequisite for OWP, and it is usually the responsibility of the Basis team. ADS setup is beyond the scope of this article; however, the main steps to set up ADS for GRC are:

  • Set up the destination in SAP NetWeaver Administrator (NWA) (Java)
  • Configure ADS document security in NWA (Java)
  • Create type G RFC destination to ADS (ABAP) 

Step 2. Test ADS. If the ADS RFC fails or if the ADS system is unavailable, the OWP Sender job short dumps and does not generate the forms. SAP delivers three standard programs that can be executed via transaction code SA38 or SE38 to test ADS. Another useful test is exporting an SAP Process Control report to PDF format. If all three programs successfully execute and reports export to PDF, ADS should generate OWP forms when required.

All results shown below are for successful tests. If the same results are not obtained in your GRC system, send the error message to the Basis team for resolution. For more information on troubleshooting ADS errors see SAP Note 944221.  

The programs listed in Tables 5, 6, and 7 test specific pieces of ADS functionality to ensure it is working properly.

Table 5 shows the first test program to determine the ADS version.

Program name

Program text


Test Program: Version Information (for Analysis Only)

Table 5
ADS test program for version information

Figures 11 and 12 show the program executed in transaction SA38.

Figure 11
Program execution in transaction SA38

Figure 12
Default ADS input parmeter

Figure 13 shows successful version information test results.  

Figure 13
ADS version information is displayed

The next test is for form processing (Table 6).

Program name

Program text


Form Processing: Central Test Program

Table 6
ADS test program for form processing

Figures 14, 15, and 16 show the program executed in transaction SA38 with required input parameters.

Figure 14
Program execution in transaction SA38

Figure 15
Default input parameters for ADS form processing test program

Figure 16
Print settings for ADS form processing test program

Figure 17 shows successful form processing test results.

Figure 17
ADS form is displayed

The next test is for generating an interactive PDF as shown in Table 7.

Program name

Program text


Generate Interactive PDF



Table 7
ADS test program for generating an interactive PDF

Figures 18 and 19 show that the program executed in transaction SA38 with the required input parameters.

Figure 18
Program execution in transaction SA38

Figure 19
SAP default values used to generate the interactive PDF (these values can be changed)

Figure 20
shows the interactive PDF was successfully generated based on the default values provided.  

Figure 20
The interactive PDF is successfully displayed. The form for Kwantlen University College is displayed with default SAP input parmeters.

The last test is to run any SAP Process Control report and export the content to PDF. In this example, the Evaluation Results by Organization report was exported to PDF. The report content should export to PDF without error as shown in Figure 21.

Figure 21
Process Control report content exported to PDF

Activate OWP Business Scenarios

To activate OWP business scenarios, follow IMG menu path  Governance, Risk and Compliance > Process Control > Offline Workflow Process > Configure OWP Business Scenario (Figure 22).

OWP currently supports 23 business scenarios. Individual scenarios can be activated by selecting the Enable check box for a specific line item. See the fifth column from the left in Figure 22. OWP support of Automated Monitoring was added in SAP Process Control 10.1 Support Package 14. The following business scenarios are NOT supported at this time:

  • Ad hoc issues (online only)
  • Remediation with Corrective Action Preventative Action (CAPA) (online only)
  • Manual control performance (SAP Fiori only)
  • Sign-off (online only)
  • Aggregation of deficiencies (online only)

Use of custom forms is supported although most SAP Process Control customers do not use them. If the names of a custom form and Handler Class are maintained for a business scenario, the custom form is used; if not, the standard SAP-delivered form is used by default. Refer to SAP Note 1633989 for information on how to customize Adobe forms.

Figure 22
Supported OWP Business Scenarios

(Note: In some cases, modification of the SAP-delivered forms or creation of custom forms requires the purchase of an additional license, so you may want to verify your license status before making modifications.)

Maintain End-User Email Addresses

The most common cause of OWP Sender job failure is that end users do not have their email addresses maintained in the GRC system. If the email address is not maintained, the OWP job associated with that user short dumps because the system is attempting to send an email to a null address. Prior to executing planner activity for OWP-enabled business scenarios, ensure that OWP users have their email addresses maintained.

(Note: As of SAP Process Control 10.1 Support Package 16, this behavior has changed. See SAP Note 2340935. Post-Support Package 16, if a user does not have an email address maintained, the child job will now complete and show a successful status in transaction code SM37. To identify users who did not receive their Adobe forms due to a missing email address, review application log entries in transaction code SLG1 instead as shown in Figures 23 and 24.)

Figure 23
Application log filtered for OWP entries

Figure 24
OWP application log entry identifying user with missing email address

Schedule a Job to Deliver an Adobe Form via Email

To schedule the  job to deliver the OWP  Adobe forms via email, follow IMG menu path Governance, Risk and Compliance > Process Control > Offline Workflow Process > Set Up Job to Deliver PDF through E-mail.

GRFN_OWP_JOB_SENDER is a parent job that manages the send process for OWP-enabled business scenarios. This job spawns a number of child jobs that run concurrently. The default value is five, but a variant can be created for program GRFN_OWP_SENDER to change that number. Each child job (one per pending work item) generates an Adobe form and emails it to the end user. The parent job executes first and keeps running until all child jobs are complete. When the last child job completes, the parent job completes. Child jobs have the work Item number in the job name and occur in blocks after the parent job (transaction code SM37) as shown in Figure 25. If more than five pending work items are waiting to be processed, they will queue and automatically release, maintaining the five active child jobs, until all pending work items are processed.   

Figure 25
One parent job with its eight child jobs

The GRFN_OWP_JOB_SENDER job checks all changed work items in between the previous job and current job that are in a state of Ready or Started. OWP-enabled work items can be processed online (My Work Inbox) or offline (OWP) at any time. The job detects which work items are eligible to be processed for OWP since the last time the job ran.  

To activate OWP functionality, schedule this job per the IMG documentation. The next time planner activity is executed for an OWP-enabled business scenario, it can be performed via OWP.

OWP Process Overview

The OWP process for a completed Control Design Assessment (CDA) is illustrated by the SM37 entries in Figure 26. Separate IDs are used for outbound and inbound email processing to provide additional clarity for the overall process.   

Figure 26
Separate IDs provided for outbound and inbound email processing

Each work item corresponds to a single stage in the overall CDA workflow process as configured in the IMG. The entries in Figure 26 correspond as follows:   

1. 110633:  CDA is processed             

2. 110634:  CDA review is performed

3. 110637:  Issue is processed           

4. 110641:  Remediation plan is processed                  

5. 110642:  Remediation plan reviewed; issue closed

This is a clean, sequential depiction of all individual work items that make-up a completed CDA. Making the same determination in a production system, however, requires a little investigation because there can be many work items in various stages of different workflow processes moving in and out of the system at any given point in time.

End-User Experience

Once the configuration is in place and the OWP process is up and running, what is the end-user experience like? The OWP process greatly simplifies and streamlines the end user’s interaction with the system. End users simply receive an email from the GRC system as shown in Figure 27.

Figure 27
The end user receives an email with an attachment from the GRC system

The end user opens the email and the attachment  as shown in Figures 28 and 29.

(Note: For information on how to customize this email, see the “Useful SAP Notes and Links” section at the end of the article.)

Figure 28
System email with the OWP form for a CDA attached

The end user opens the attachment, completes the form, and clicks the Submit button (Figure 29).

Figure 29
Completed OWP form

An email is automatically created with the completed form attached and it is automatically addressed to the inbound email processing ID defined in step 2. The user then clicks the Send button in Figure 30 to send the attachment back to the GRC system.

Figure 30
Auto-generated email ready for submission to the GRC system

The content of the Adobe form successfully updates the GRC system and the user receives a confirmation email (optional) as shown in Figure 31. As far as the system is concerned, there is no difference whether the workflow was performed online or offline.

Figure 31
Confirmation email of successful form submission

(Note: The confirmation email was introduced in SAP Process Control 10.1 Support Package 14 [SAP Note 2371279]).

Troubleshooting Errors

OWP errors can occur with both outbound and inbound processing. The transactions in Table 8 are helpful for troubleshooting errors.

Transaction code

Transaction text



Application Log: Display Logs

Detailed error information (very useful)


ABAP Dump Analysis

Review unexpected program termination


Job Overview

Review inbound/outbound OWP Job status and logs


SAPconnect Send Requests

Review outbound email status


BCS: Inbound Send Requests (SMTP)

Review inbound email status

Table 8

Transactions useful for troubleshooting errors

Known errors are listed in the next sections. However, the list is by no means comprehensive as new and unanticipated system activity can cause OWP errors. The application log is a great source of information when troubleshooting OWP errors. If a short dump exists, carefully check transaction code ST22 for clues about the failure. When all else fails, enlist the assistance of an SAP support representative to debug the problem.  

Outbound Errors

The parent job GRFN_OWP_JOB_SENDER rarely fails. When the child jobs fail, it is usually due to a missing dependency required to generate the Adobe form and email it to end users. Although there can be several possible causes for the failure of a child job, they all usually result in the same ASSERTION FAILED short dump shown in Figure 32.

Figure 32
OWP Sender job short dump

Use transaction code SOST to determine the status of outbound email as shown in Figure 33. Red is a hard error, meaning the system did not send the email. Yellow means the email was placed in the outbound queue and the system will send it the next time the SAPCONNECT_ALL_SEND job runs. Green indicates a successful email transmission from the GRC system.

Figure 33
Outbound email queue

Common causes of outbound job failures are listed below in the order of frequency:

1. The email address is not maintained. If the end user’s email address is not maintained in the GRC system, all child jobs associated with pending work items for that user will fail. Once the email address is maintained, the child jobs will successfully complete the next time the GRFN_OWP_JOB_SENDER job runs. A clue for this type of problem is that some child jobs complete from the original block of work items while others fail (Figure 34). This points to a problem with an individual user or work item.

Figure 34
Individual child job fails until the end user’s email address is maintained

Details within the short dump indicate a problem with the email address (Figure 35).

Figure 35
Short dump shows an issue with user’s email ID

(Note: As of SAP Process Control 10.1 Support Package 16, this behavior has changed. The child job will no longer fail due to an unmaintained email address; an entry will be created in the application log instead, as shown in Figure 24. See SAP Note 2340935.)

2. ADS is inaccessible. If there is a problem with the ADS RFC or if the ADS system is down, the parent job will complete, but all child jobs will fail as shown in Figure 36. If this happens, confirm connectivity to ADS per the “Test ADS” step above. Once ADS is accessible, all child jobs will complete for pending work items the next time GRFN_OWP_JOB_SENDER runs.

Figure 36
Child job failures when ADS is not accessible

3. There are problems with the outbound email processing ID. The ID executing the GRFN_OWP_JOB_SENDER job must be unlocked, valid, and have the appropriate authorization. If not, the parent job will fail and it will not create any child jobs. When the parent job fails (Figure 37), check the outbound email processing ID.

Figure 37
OWP parent job failure

4. An 0 KB attachment size was uploaded. There have been instances in which an attachment with a size of 0 KB was uploaded into the GRC system causing child jobs to fail. In both cases, clues to the cause were found in the short dump.

  • An attachment with a size of 0 KB was uploaded to the Attachments and Links tab of a local control, which caused the child job to fail the next time it was planned. The solution was to delete the attachment.  
  • Another attachment with a size of 0 KB was uploaded into the OWP form as an attachment for a work item. The attachment successfully posted to the system on the inbound email. However, it caused the child job to fail when the CDA was sent for review. The solution was to delete the case and workflow, then replan the work item.
Inbound Errors

Transaction code SOIN shows inbound email received by the system. When you troubleshoot problems, the first step is to ensure the system received the email. Each entry in SOIN should be completely populated, including the Internal Recipients field shown in Figure 38. If Internal Recipients is not populated, there is a problem that prevented the form content from posting. Even if the SOIN entries are fully populated, there can still be other downstream problems that prevent the form content from posting.

Figure 38
Inbound email list

To view the content of Adobe forms submitted to the system, double-click the line item, and then click the attachment link in Figure 39.

Figure 39
Inbound email received by the GRC system with the OWP form attached

Common causes of inbound email failures are as follows.

1. Problems with the inbound email processing ID include a locked or invalid ID. If the inbound email processing ID is locked or invalid, transaction code SOIN does not record an entry. The end user receives an email with the subject Undelivered Mail Returned to Sender (Figure 40).

Figure 40
System-generated email for undeliverable email

Another issue with the inbound email processing ID is a security error. If the inbound email processing ID encounters a security error, transaction code SOIN shows an entry for receiving the email, but the Internal Recipients field is blank (Figure 41). The inbound email background job does not execute, and the form contents will not post to the system.    

Figure 41
Security error prevents the OWP form from posting to the system

2. Problems with the end user’s ID include a locked or invalid ID. If the ID of the OWP user is locked or invalid, transaction code SOIN shows a successful entry for receiving the email, but the inbound email processing job fails (Figure 42). The SM37 log entry for the canceled job indicates there is a problem with the end user’s ID (Figure 43).

Figure 42
Inbound failure due to a locked or invalid end user ID

Figure 43
SM37 log entry for the inbound failure

The end user’s ID could also have a security error. If the end user’s ID encounters an authorization error, all entries in transaction codes SOIN, SM37, and SLG1 appear successful, but the content of the form will not post to the system.

3. ADS is inaccessible. If ADS is inaccessible, transaction code SOIN shows an entry for receiving the email, but the field for Internal Recipients is blank (Figure 44). In addition, the content of the form will not post to the system and the inbound email processing job will not execute.

Figure 44
When ADS is down, internal recipients are not identified

Upon further investigation of the application log there is an error message referring to ADS (Figure 45).

Figure 45
Application log entries identify a problem with ADS

4. There is a form or email problem. Under certain circumstances, transaction codes SOIN, SM37, and SLG1 all show successful entries, but the form will not post to the system. When this happens, look at the inbound email in transaction code SOIN. This type of problem can happen when:  

  • The end user manually adds an additional attachment to the inbound email.
  • The end user manually creates and submits the email to the system instead of using the Submit button in the form. As of SAP Process Control 10.1 Support Package 16, the user receives an automated email response if a manually created email is submitted to the system.  

5. The date format does not match. The date format of the OWP end user must match the date format of the ID that generated the Adobe form. If not, the inbound email processing job will fail. The SM37 log for the cancelled job indicates there is a problem with the date format (Figure 46).

Figure 46
SM37 log entry identifies a problem with the date format

(Note: This issue was resolved as of SAP Process Control 10.1 Support Package 16 [SAP Note 546147]).

Automated System Messages for Inbound Email Processing

Automated email responses are sent by the system under certain circumstances. Some responses are error messages; others are notifications.  

1. The task you submit has already been finished by XXXX (Figure 47). Your result will be ignored.

Figure 47
A system-generated email that the task is already finished

Cause:  Depending on security structure and role assignments, a work item can have more than one potential processor. When the system processes work items online, the Work Inbox is based on a “first-come, first-serve” principle that allows a user to reserve a work item so it’s not accessible to other potential processors. Reserving work items is not possible for OWP because work items are processed offline.

Solution: No action is required.

2. This form should be submitted by the user who has received the original task (Figure 48).

Figure 48
A system-generated email that the originating user must submit the form

Cause 1:  User A forwarded the email to user B for processing. User B submitted the form to the GRC system.

Solution 1:  User B sends the email back to user A for submission to the GRC system.

Cause 2:  Users can have more than one valid corporate email address. The email address maintained in the GRC system must match the end user’s default corporate email address (the user’s default From address when sending email) or the GRC system will not associate the inbound email with the end user to whom it was sent.

Solution 2:  Change the user’s GRC email address to match the default corporate email address.

3. The following error exists in the back end. Please contact your system administrator. Work item XXXXX is not in the users work inbox (Figure 49).

Figure 49
A system-generated email for submitter when delegated authority is active

Cause: Delegated access is active for the user submitting the Adobe form.

Solution: Log on to the GRC system, undelegate access, and resubmit the form.

4. The following error exists in back end. Please contact your system administrator. Error in inbound handling of PDF form (Figure 50).

Figure 50
A system-generated email for improper form submission

Cause: The user manually created the email to submit the form instead of using the SUBMIT button in the form.

Solution: Resubmit the form using the SUBMIT button in the form.

(Note: This notification was introduced in SAP Process Control 10.1 Support Package 16.)

Tips and Tricks

The following tips and tricks are useful when working with OWP.

1. Use separate IDs for outbound and inbound email processing. The use of separate IDs for outbound and inbound email processing is helpful when troubleshooting errors. The direction of the work item is known by looking at the ID associated with the entry.

2. Add the Work Item ID column to your Work Inbox. Go to your Work Inbox, click the settings icon, and add Work Item ID to the displayed columns (Figure 51). This step is helpful when delegating access and troubleshooting errors.

Figure 51
Process Control Work Inbox with the Work Item ID field

3. Make the email address a required field. The end user’s email address drives the OWP process, so it is critical that it is consistently maintained in the GRC system. By far, the most frequent cause of OWP sender job failure is that end users have a blank email address in the GRC system. To reduce these errors, find a way to make email address maintenance required. Ideally, an automated solution such as Identity Management (IDM) or SAP Access Control will automatically maintain the email address upon user creation. If end-user administration is more of a manual process, consider creating a standard screen variant in transaction code SHD0 to make maintenance of email address fields required. This step ensures that whenever a security administrator maintains the end user’s information in transaction code SU01, email-relevant fields must be maintained as well.

4. Maintain the attachment size limit. Just as attachments are uploaded into work items from My Work Inbox in the GRC system, attachments can also be added to the OWP form; however, the size of the attachment can be limited. Use transaction code SM30 to maintain table view GRFNV_OWPALSIZE to maintain the maximum size limit for OWP attachments (Figure 52). Attachments over the limit will not be accepted by the Adobe form. The limit should be less than the maximum attachment size allowed by corporate email servers. This step ensures that GRC system-bound emails are not intercepted for exceeding the corporate size limit.  

Figure 52
Specify an OWP email attachment size limit

5. Resend Adobe forms to end users. End users sometimes delete or lose the OWP email and need it to be sent again. This can be done either with transaction code SOST or with program GRFN_OWP_SENDER_TEST. Transaction code SOST can be used to resend the original email with the Adobe form as originally generated. Program GRFN_OWP_SENDER_TEST will regenerate the Adobe form and resend the email.

a. Execute transaction code SOST (Figure 53). Locate the original email and select the line item. Go to Send Request > Repeat Send.

Figure 53
Repeat the sending of the original email

The line item will turn yellow. Select the line item, click the execute icon, and select Start Send Process for Selection (Figure 54). The original email will send again and the line item will turn green.

Figure 54
Resend the original send request

Execute program GRFN_OWP_SENDER_TEST. Run transaction code SA38 or SE38 and execute program GRFN_OWP_SENDER_TEST (Figure 55). This program regenerates and resends the Adobe form based on current master data. This is useful in situations in which the control master data has changed since the form was originally sent and those changes are required for the end user to process the work item. It’s also useful if a user has no email address or the wrong email address is maintained in the GRC system. Once the email address is updated, this program can be used to immediately resend the Adobe form to the user without waiting for the GRFN_OWP_JOB_SENDER job to run again.

Figure 55
Resend OWP form for Workitem 110693

6. Limit users who can receive email from the system. The GRC system must be able to send email for the OWP process; however, there is a risk that OWP email from a development or QA system could accidentally be sent to end users, causing confusion or complaints. One way to prevent this from happening is to limit which users can be sent email from the GRC system. This allows select users to fully test the OWP process while preventing accidental mass-email incidents.

Execute transaction code SCOT and follow menu path Business Communication Administration > Settings > SMTP Connection > Outbound Messages > SMTP Nodes. This path takes you the screen shown in Figure 56. Expand the SMTP folder and double-click the Internet node.

Figure 56
SMTP node navigation for user restrictions

Maintain entries in the Address area for email addresses that are allowed to receive email from the system (Figure 57). If a user’s email address is not maintained in the list, the system will not send them email. Wildcard values are acceptable. Production systems typically do not limit users who can receive email so * values are used.

Figure 57
Email address list to which the GRC system is allowed to send

Any email the system attempts to send to a user not listed in the Address area will remain in error status until the entry is corrected as shown in Figure 58. To see emails in error status, execute transaction code SOST. Once corrected, emails in error status can be manually resent as described in the “Transaction SOST” section.

Figure 58
Outbound send requests in error status

7. Arrange for ad hoc execution of job GRFN_OWP_JOB_SENDER. The GRFN_OWP_JOB_SENDER job is a recurring job that executes on a regular interval. In the example below, this job is scheduled to run every 10 minutes in the DEV and QA systems. During testing, however, you may want to run the job immediately without having to manually execute it or wait for it to run according to the schedule. There is a way to execute it on an ad hoc basis while leaving the recurring schedule intact.

Execute transaction code SM37. Find the GRFN_OWP_JOB_SENDER in Released status (Figure 59). Click the check box to select that line item.

Figure 59
GRFN_OWP_JOB_SENDER job in Released status

Click the Job button and then select the Change option as shown in Figure 60.

Figure 60
Change the GRFN_OWP_SENDER JOB in Released status

Click the Start condition button in Figure 61.

Figure 61
Maintain the Start Condition

Click the Immediate button and then click the save icon (Figure 62).

Figure 62
Execute the job immediately and save your changes

Click the save icon again (Figure 63).

Figure 63
Save all changes to GRFN_OWP_JOB_SENDER

The job executes immediately and displays the message “Job GRFN_OWP_JOB_SENDER changed” at the bottom of the screen. The schedule remains intact and the job runs again 10 minutes after the last execution. As shown in Figure 64, the job originally ran at 44 minutes after the hour. It was manually executed at 47 minutes after the hour, and then the recurring job resumed (10 minutes later) at 57 minutes after the hour.  

Figure 64
Execution times of GRFN_OWP_JOB_SENDER job before and after change

8. Identify user IDs with missing email addresses. When an OWP job fails due to a missing email address, there is a way to identify the user ID associated with the work item number. This method is most useful prior to SAP Process Control 10.1 Support Package 16 (SAP Note 2340935). To identify the user ID, execute transaction code SE24 (Figure 65). Enter class name CL_GRFN_PROCESS_UTIL and click the Display button.

Figure 65
Enter the class name

Select the GET_WF_AGENT method in Figure 66 and click the test icon.

Figure 66
Test the method

Click the execute icon for the GET_WF_AGENT method (Figure 67).

Figure 67
Execute the method

Enter the work item ID (70745) and click the execute icon (Figure 68).

Figure 68
Enter the Workitem ID

Click the icon for 1 Entry (Figure 69).

Figure 69
Click the icon to view results

The user ID associated with the failing OWP child job is revealed (Figure 70).

Figure 70
The user ID for the failing work item is displayed

9. Disable workflow notification email for OWP-enabled work items. Follow IMG menu path Governance, Risk and Compliance > General Settings > Workflow > Workflow Email Notifications > Maintain Workflow Notifications. Part of standard GRC system setup involves activating Business Configuration Sets (BC Sets) for workflow email notification. Once activated, the BC Sets contain default entries for different types of email notifications. When users receive a new work item in their Work Inboxes, the GRC system sends an email notification notifying them about it. This notification typically has a subject of New work items in your Workflow inbox (Figure 71).

Figure 71
Standard workflow notification email

This notification is unnecessary for work items associated with OWP-enabled business scenarios and it should be disabled. The example used for this entire section is to disable the standard email notification for all work items associated with assessments.

a. Create a Category. Execute transaction code SWNCONFIG. In the screen that appears select the Scenario GRCNOTIFICATION and double-click the Category folder (Figure 72).

Figure 72

Click the copy icon (Figure 73).

Figure 73
Copy category notification

Change the Category and Description field names and press Enter (Figure 74).

Figure 74
Maintain new Category info

Click the copy all button (Figure 75).

Figure 75
Copy all dependent Category records

Press Enter three times to copy all dependent entries (Figure 76).

Figure 76
Copy individual dependent records

Click the green checkmark icon (Figure 77).

Figure 77
Confirm total records are copied

Click the save icon (Figure 78).

Save records for new Category ZNOTIFICATION

b. Create a Filter. Select the GRCNOTIFICATION line item and double-click the Filter Basic Data folder (Figure 79).

Figure 79
Maintain Filter Basic Data

Click the copy icon (Figure 80).

Figure 80

Maintain the Filter and Description fields (Figure 81). In general, the name should be in the customer name space (beginning with a Z or Y) and the description field should be descriptive and meaningful.

Figure 81
Maintain new Filter information

Press Enter and then click the copy all button (Figure 82).

Figure 82
Copy all dependent Filter entries

Click the green checkmark icon (Figure 83).

Figure 83
Confirm Total records copied

Click the save icon (Figure 84).

Figure 84
Save records for the new filter

Change the entries of the Main Filter and Category fields to the entries just created (ZGRCNOTIFYFILTER; ZNOTIFICATION). Click the save icon (Figure 85).

Figure 85
Maintain a new Filter definition

c. Modify Filter Settings. In this example, all workflow tasks associated with assessments, as previously mentioned,  will be deactivated for workflow email notification since OWP will be used for assessments. Tasks related to assessments that must be removed from the filter are: 
  • TS75900006 Start Issue Remediation
  • TS75900007 Perform Assessment
  • TS75900008 Review Assessment
  • TS75900009 Rework Assessment
  • TS76307972 Enter Details for Remediation Plan
  • TS76307973 Report on Remediation Plan Progress
  • TS76307974 Review Remediation Plan Details
  • TS76307975 Review and Close Remediation Plan

Select Business Scenario GRCNOTIFICATION. Double-click Filter Basic Data and select the filter that was just created. Double-click the Filter settings folder (Figure 86).

Figure 86
Select a custom filter

Select all the entries to be removed. Click the delete icon. Click the save Icon (Figure 87).

Figure 87
Remove tasks

d. Maintain Schedule Selection. Double-click the Schedule Selection folder. Change the name of the filter for Scenario GRCNOTIFICATION to the filter just created (ZGRCNOTIFYFILTER). Click the save icon (Figure 88).

Figure 88
Modify the schedule selection to use the new filter

The next time the workflow notification job runs, email notifications for all assessment-related tasks will not be sent.

Useful SAP Notes and Links

For more information check these SAP Notes:                                             

  • 455140 - Configuration of e-mail, fax, paging/SMS via SMTP
  • 546147 - SMTP plug-in: MS Exchange sends only to port 25
  • 894009 - Adobe Document Services Configuration Guide [SAP NW 7.0]
  • 944221 - Troubleshooting if problems occur in forms processing
  • 750784 - SAP Interactive Forms: Licenses
  • 1633989 - Technical user guide for OWP
  • 1866809 - OWP job for WI failing and ST22 Assertion Failed dump
  • 2085529 - OWP ASSERTION_FAILED Master Note
  • 2210385 - Consolidated Note for Process Control 10.1 – OWP
  • 2371279 - Confirmation email for Disc Survey
  • 2028284 - Multiple emails generated for same work item
  • 2340935 - ST22 dump for sending notification email via GRFN_OWP_SENDER - user id, email id not in system
For more information check these links:
PROT = SMTP, PORT = <port>

Form Processing: Central Test Program

Job Overview

Job Overview

Job Overview

An email has been sent to:


Jan Gardiner

Jan Gardiner (, CPA, is a senior director in GRC Solutions at SAP Labs, LLC. She is the solution owner of SAP Process Control for compliance and control management, responsible for product direction and go-to-market activities. She has been involved with compliance software at SAP for more than 12 years and has worked closely with customers in a variety of industries and geographies. You can follow her on Twitter @Gardiner_AZ.

Matt Hartnett

Matt Hartnett ( is an SAP security and SAP Process Control consultant with over 18 years of experience. He has worked with multiple Fortune 500 companies designing and implementing SAP security strategies and SAP Process Control compliance initiatives (with use of SAP Interactive Forms by Adobe).  He has successfully completed several Process Control implementations and upgrades.

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!