8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 1/13

Workflow Development Standardscreated by Modak Gupta on Jul 31, 2014 3:42 PM, last modified by Modak Gupta on Aug 18, 2014 11:01 AM

Version 5

This is a subsequent document to SAP Workflow Strategy posted here on SCN - The Workflow Strategy forms the basis of Workflow

Development Standards. 

I have tried to draft the following Workflow Development Standards for one of my projects. I thought itwould be useful to share it and most importantl y  get some reviews, comments and suggestions from ouresteemed workflow fraternity so that we can improve these further. I have already tried to includewhatever I have learnt from the experienced members of this group. Please feel free to provide yoursuggestions 

Workflow Developments 

Before any workflow development can begin, it is expected that Automatic Workflow Customizing has beenperformed in your system. 

1.1.1. Important questions to ask before starting your Workflow development

Here is a neat blog which explains some basic questions to ask before starting a workflow development.It is important to know these requirements because these can impact the design and delivery timelines ifdiscovered later on. Please refer the link Workflow functional specifications design 

1.1.2. Workflow Task Development

1.1.2.1. Workflow Prefix Number Range

Definition: Range of numbers that can be assigned to workflow development objects e.g. WorkflowTemplates, Standard tasks and Standard Rules. Standard: Number Range used should be between 900 and 999.  

Each SAP system (ECC, CRM, HCM etc.) should use a different number to help differentiate differentworkflows 

No number ranges should be defined in QA and production as no development will be done in thesesystems. 

1.1.2.2. Multi Step Tasks (Workflow Template / Definition)

 A multi-step task (workflow template) consists of a sequence of steps to be performed either by a personin dialog, or by the workflow batch user in background. A number of steps types (e.g. conditions, events,forks, operations etc.) inside the workflow can be used to control the processing sequence of the tasks. Workflow Template Naming Standard 

The following is a guide only, but should be adhered to when practical. When using a copy of a SAPstandard template with only minor modifications it may be preferable to just put a Z in front of the originalname. 

Mask   Z  XX   _   XXXXX   _   Vn 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 2/13

 

| |  |  |  |  Version 

Number tocontrol 

|  |  |  | major changes afterGo- 

| |  |  |  |  Live 

| |  |  |  |  Underscore 

|  |  |   Abbreviated Description  – May also include 

|  |  |  an indicator for sub flows 

|  |  Underscore 

|  Process Area 

|  E.g. PS  – Project Systems 

| MM  – MaterialsManagement 

|  FI  – Finance 

Custom development character indicator  

Please note that the naming convention can vary based on your project settings. Another approach can be to add functionalmeaning into the abbreviation that is not found elsewhere. e.g. "Apr" for approvals, "Auto" for automation, "Exc" for exception handling. We can also addBG/Dlg where it is not obvious.

One could even argue the z isn't needed as the leading '9' already makes it clear it's a custom workflow. Moreover, focus on u sing the right package for the

workflow to be able to list them via package in SE80.In summary, use the Naming which best suits your project.

1.1.2.3. Basic Data:

 Always have the business object key of the triggering object in the workflow work item text. 

1.1.2.4. Description:

In the workflow template description record the triggering mechanism (e.g. transactions, user exits,reports, change documents) and a basic process overview. When standard workflows are copied, note

down the SAP template name and abbreviation in the task description. 

1.1.2.5. Triggering Event:

 Always ensure that the binding to the initiator is complete, and the object is bound in correctly to anelement used in the workflow process. N.B. if you are using object container elements created byinserting tasks in the process then ensure these are checked as Import Parameters before inserting theevent. 

1.1.2.6. Agent Assignment:

When using Start forms/Transactions, or „Start Workflow‟ functionality, ensure that the agent assignmentis maintained, otherwise leave unassigned. This will always need to be assigned for SRM workflows andthose directly started by web forms (such as ESS Leave Request). Include the agent assignment in aCustomizing TR using RHMOVE30 (Refer following article on the details of RHMOVE30usagehttp://scn.sap.com/docs/DOC-51922) 

1.1.2.7. Container Elements:

Create container elements for all known import parameters (whether objects or single fields) beforeinserting the triggering events, this will make bindings easier. E.g. Workflow is triggered from a material

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 3/13

create event  – create a container element called BUS1001_OBJ first (for objects use the technical nameof the object plus _OBJ (indicator for object)) and then bind the event object to this element. 

1.1.2.8. Header Data (Workflow Builder)

Where appropriate maintain a workflow administrator in the Responsible tab  

1.1.2.9. Step Data:

 Always maintain step outcome names (useful for workflow logs).  

Only foreground steps should be marked visible in "All workflow Logs" (tab Details) - rest of the stepsshould be marked "Only in Technical Workflow Logs". 

1.1.2.10. Agent assignment:

 Always try to use Rules for Agent determination instead of object methods called in preceding steps.  

Never assign a step directly to an organizational object or user id. Instead either use an Expression, arule, or if specific enough, just use possible agents. The idea is to only use soft links rather than enteringids that would have to be changed by a transport. Include the agent assignment in a Customizing TRusing RHMOVE30 (Refer following article on the details of RHMOVE30usage http://scn.sap.com/docs/DOC-51922) 

1.1.2.11. Single Step tasks (Standard Tasks)

IMPORTANT: As a base rule, always club functionality of multiple background steps into one, as much aspossible. Each background step involves a tRFC call, which in itself takes about a second. So if yourworkflow has 5 background steps to do different activities before a dialog step, the workflow runtimewould need 5 seconds minimum (plus the execution time of those steps) to get to the dialog step. Bestapproach is to combine them into one step (of course you can call five individual methods in one methodand call that one in a singlebackground step). 

 A standard task is a step executed either by a user in dialog, or the workflow batch user in background.

Standard Tasks typically call object methods to deliver the required functionality to a user, however, whenlinked to web functionality a variety of techniques can be used to link the task and the web screen.  

Standard Task Naming Standard 

Mask   Z  XX   _   XXXXXX   _   N 

|  |  |  |  | 

One Digit Number(optional) 

|  |  |  |  | 

|  |  |  |  Underscore 

|  |  |   Abbreviated Description 

|  |  | 

|  |  Underscore 

|  Process Area 

| E.g. QM  – Quality Management 

|  MM  – Materials Management 

|  FI - Finance 

Custom development character indicator (Z orY) 

Length  12 Characters 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 4/13

 

Please note that the naming convention can vary based on your project settings. Another approach can be to add functional

meaning into the abbreviation that is not found elsewhere. e.g. "Apr" for approvals, "Auto" for automation, "Exc" for exception handling. We can also addBG/Dlg where it is not obvious.One could even argue the z isn't needed as the leading '9' already makes it clear it's a custom workflow. Moreover, focus on using the right package for the

workflow to be able to list them via package in SE80.In summary, use the Naming which best suits your project.

1.1.2.12. Use of Super Type Objects

 Always use standard (super type) business objects in the object method section. Any enhancementsshould be available through delegation. 

1.1.2.13. Work Item Text

 Always maintain a work item text, even if the item is to be executed in the Background (in this case beginthe text with „BCKGRD :‟). If the requested text is too long for the field then create short containerelements to help fit in extra variables  – populate with the step binding from object attributes.For Foreground Steps, always start with a verb, example  Approve: Leave Request by user XYZ... 

Ensure to have dynamic values in the Workitems text, preferably the key (example the PO number orDocument number) so that the task can be differentiated for a specific document in transactions like SWI1or SWI5 or SBWP. 

1.1.2.14. Deadline TextsIf „Simple Deadlines‟ are to be used then ensure the relevant texts are maintained. 

1.1.2.15. Terminating Events

Use terminating events when appropriate to ensure a user has completed the relevant tasks required andto allow the workflow to respond standard transactions outside of workflow. 

1.1.2.16. Possible Agents

Ensure that relevant possible agents are maintained. The task should at very least be classified as aGeneral Task. Include the agent assignment in a Customizing TR using RHMOVE30 (Refer followingarticle on the details of RHMOVE30 usage http://scn.sap.com/docs/DOC-51922) 

1.1.2.17. Task Groups

Task Groups are a collection of standard tasks, workflow templates and other task groups, which areused in a common context. You can set up hierarchies of task groups by inserting task groups into othertask groups. Tasks groups are the preferred option for possible agent assignment where more than one task shares apossible agent assignment  – this speeds up agent assignment after transports. 

Task Group Naming Standard 

The following standard should be used where practical: 

Mask   Z  XX   _   XX   _   XXXXX 

| |  |  |  |  Task  Group   Abbreviated 

|  |  |  |  Description | 

|  |  |  |  Underscore 

|  |  |  Functional area 

|  |  |  E.g. PR  – Purchase Requisition 

|  |  |  QN  – Quality Notification 

|  |  |  QB  – Quantity Block 

|  |  Underscore 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 5/13

  | Process Area 

| E.g. QM  – Quality Management 

|  MM  – Materials Management 

|  FI - Finance 

Custom development character indicator  

Length  12 Characters 

1.1.3. Using ABAP Classes in Workflow

1.1.3.1. Custom Class Development

A relatively new feature within SAP Business Workflow is the possibility to use ABAP objects instead of BOR objects.  ABAP objectsuse the newer ABAP editor and enforce improved coding standards by only allowing the use of object-oriented ABAP standards and syntax. Object Type which was earlier the base building block of workflow development, could still be used withinor in combination of the ABAP class to make use of existing functionality delivered by SAP. Object Types encapsulate functionality within SAP in an „object wrapper‟ and can be accessed uniquelyunder an identifying key, normally comprising the keys of an ABAP Dictionary table. 

Objects are instantiated at runtime by assigning key fields to an object type. There are many eventsassociated with BOR objects that happen natively in the SAP system and these must be considered for

triggering a workflow in SAP business suite applications. 

Enhancing standard objects or using Subtypes is not a best practice anymore and we must make use of ABAP classes instead. 

Refer the following links (in the given order) for further details of using classes in Workflows:  

1.  Why use ABAP OO with Workflow?  

2.  Getting started with ABAP OO for workflow  

3.  Using ABAP OO Methods in Workflow tasks 

4.  Raising ABAP OO Events for Workflows 

5.  Using ABAP OO Attributes in Tasks 

6.  Using Functional Methods in Workflow Tasks 

7.  Referencing BOR Objects in ABAP OO Classes 

1.1.3.2. Extending existing Objects: - [Avoid using subtypes for custom functionality. Instead, use ABAPClasses] 

When extending an existing business object through subtypes, add „Z‟ as a prefix to the SAP businessobject.  Always use delegation in order to use the standard SAP business object in all tasks and workflows. Aswell as enabling the use of standard functionality which may already be in the system, this also enablesfeatures such as Generic Object Services. 

1.1.3.3. Program Name, Object Name, Name and Description –  [Relevant for Subtypes; Avoid using

subtypes for custom functionality. Instead, use ABAP Classes] 

Same as Object Type and any additional information could be added to the description. 

1.1.3.4. Defining ABAP ClassThe key to enabling a class to be used in workflow is the IF_WORKFLOW interface. Simply defining it in theclass makes it available to use in the workflow builder and task editors. We may still use standardbusiness objects to trigger the workflow but for any enhancement, we must use class. 

1.1.3.4.1.Methods

Handling Methods of IF_WORKFLOW 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 6/13

Please refer  Why use ABAP OO with Workflow for the usage of the IF_WORKFLOW Interface methods. Ifyou will be leaving any method empty, it is good to comment the reason inside the coding block and alsoplace a RETURN statement to avoid unnecessary EPC / CI warnings for empty methods of classes. 

Special Method - CREATE_INSTANCEIf your workflow is based on a standard BO and you further need custom attributes and methods, define an ABAP Class with IF_WORKFLOW Interface.

Handling of IF_WORKFLOW methods is described in the blogs given above.

However, you would first need to create a runtime instance of your class in the workflow in order to read the Attributes and to access Instance Dependentmethods. To achieve this, do the following:

1.  Create the KEY fields (of the base BO) as attributes of the class and set the Key check box for these fields

2.  Create a Constructor for the class and populate the necessary attributes via the Constructor coding

3.  The Constructor should have the Key field(s) as the importing parameter(s) In your ABAP Class, define a Public Static method, example

CREATE_INSTANCE with importing parameter as the Key of the base BO and one exporting parameter: TYPE REF TO the same ABAP Class

4.  Within CREATE_INSTANCE, issue the command CREATE OBJECT to create the instance of the same class - this will essentially call the constructor

and set the attribute values for you

5.  Pass back that instance in the exporting parameter of the method CREATE_INSTANCE

6.  Within your workflow, as a first step, call this method via an activity step and bind back the class runtime instance to be used later on

A special handling is required for method BI_PERSISTENT~FIND_BY_LPOR  to prevent multiple instantiation of the ClassObject at runtime. 

The concept is explained via an example of a Service Entry Sheet Workflow where the Key field isSES_NUMBER (Type LBLNI - Entry Sheet Number) and the ABAP OO Class name isZCL_MM_SES_WORKFLOW 

The method FIND_BY_LPOR will be called by the workflow runtime to get the Persistent BusinessInstance (RESULT) by passing the Local Persistent Object Reference (LPOR). 

The purpose of this method is to provide an instance of the class. Now, to prevent multiple instantiation atruntime (for multiple calls), ensure to save the first created instance in a STATIC TABLE  

In our example, the table is defined as: 

This table GT_EXISTING_INSTANCES is of  Direct Entry Type, which is defined as: 

The TYPE GTY_SES_INSTANCES is defined in the TYPES Section of the class, which again is a  Direct

 Entry Type: 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 7/13

 

The definition of this type has one field for the KEY (SES_NUMBER) and one field for the ObjectReference (reference to self class): 

Coming back to method FIND_BY_LPOR, first check if we have an instance in this table, if yes, pass thatback else create a new one, save in this table and then pass it back. The following screen shot explainsthe entire coding process in detail. 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 8/13

 

 ABAP classes have an additional advantage of making use of functional methods unlike BOR methods.Functional methods give flexibility to be directly called from within the binding (Refer  Using FunctionalMethods in Workflow Tasks) 

If the method is used as a place holder for web functionality (example Leave request Approval) then it isrecommended that if the user could possibly execute the item from SAPGUI they should be displayed a

dialog pop-up to inform them that they are using the wrong inbox and then trigger an exception. ReferStandard Task TS12300097 as an example.  

Naming Standard: 

Follow Class Naming Guidelines. 

Development Standards: 

Import and export parameters should be used to pass data to and from a method. ABAP class methodsdo not have a result parameter like the predecessor BOR objects but they do have returning parameterwhich is used in functional methods. Use functional methods to return the instance of the class. 

Public Methods: 

Only Public methods can be used inside workflow. Private Methods: 

Private methods are well suited to implement support functions and subroutines.  

1.1.3.4.2.Exceptions

Exceptions should be used to trap any errors. Following exceptional classes are available to be used asa superclass for creating a Z class in SE24.  

CX_BO_TEMPORARY 

CX_BO_ERROR 

CX_BO_APPLICATION 

Temporary Exceptions should be used for any temporary errors such as „Document Locked by …‟ Ensurethat when creating a custom exception class, we check the "With Message Class" flag. All messagespassed in this manner are visible in the workflow log and the long text can be viewed for furthertroubleshooting options. For the message used in exceptions we should include the following to enable the where-used list for themessage from SE91: 

Note that this will result in an EPC warning for „Impossible Condition‟, which can be hidden by the pragma##BOOL_OK (Check with your lead if pragma usage is permitted or it should be an approved exceptionvia ABAP Test Cockpit - Take a look here and here, or scroll down to see a screenshot here) 

Example of using an Exception nested within methods is follows. 

Here, the method CREATE_INSTANCE is a STATIC PUBLIC method, called from a workflow task toinstantiate the class object. This method creates an object of the class and returns it to the caller.CREATE OBJECT statement will call the CONSTRUCTOR, which in turn is responsible to populate theclass attributes. In our example, the CONSTRUCTOR issues exceptions based on various conditions.The issued exception has to be propagated upwards by the caller (method CREATE_INSTANCE) so thatthe messages are visible in the workflow log. 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 9/13

 

The caller, CREATE_INSTANCE, has to trap the same exception and propagate it upwards: 

If this propagation does not happens, the workflow log will not show the exact error message; it will display a generic error "Exception

Occurred in Method <Name> of Class <Name> ; which does not gives the exact reason of error. 

Naming Standard: 

ZCX<Name of standard exception superclass> 

Example: ZCX_BO_EXCEPTION 

1.1.3.4.3.Attributes

 Attributes are the characteristic features of an object. The possible attributes of an object are defined aspart of the object type definition in the Business Object Builder. Attributes can be used to formulateconditions in the workflow definition and are also used in work item texts. The object attributes are read ordetermined at runtime. In case of ABAP class, we should only create public attributes for any fields youwant to use in workflow. For any fields to be used internally, we should create private attributes.  

Ensure that there is at least ONE KEY Attribute which can uniquely represent the instance. 

Naming Standard: 

New attributes may start with Z and then any descriptive text, new words starting with uppercase. Pleaseapply the Class naming guidelines 

Development Standards: 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 10/13

For static attributes (e.g. created by) ensure that the object buffers are checked before any calculationsare performed to improve object efficiency. Only very dynamic attributes should not include a buffercheck. If a virtual attribute is particularly complicated, involving multiple selects, consider how widely it is used indifferent workflows. If it is only used in very limited places in the workflows (and particularly when abusiness object is used in multiple processes) then consider using a background method to calculate thevalue for that process. 

1.1.3.4.4.Events

Events signify when something has happened to a business object for example: "Invoice entered","Purchase order released". The list of possible events is defined for an object type. This list can be extended according to customerrequirements using the delegation concept. However, you have to ensure that the events are actuallyraised in the application (or can be raised using customizing or development). 

Naming Standard: 

New events should start with Z and then any descriptive text, new words starting with uppercase. 

1.1.4. Workflow Agent Rules

Rules determine the selection of the specific agents during the running instance of a workflow process.Rule resolution takes place at runtime depending on the information from the current process. The resultof rule resolution is an agent, or a list of agents, who are responsible for the actual processing of the task. 

Naming Standard 

Mask   Z  XX   _   XXXXX   _   NN 

|  |  |  |  | 

Two characternumber  

|  |  |  |  | 

|  |  |  |  Underscore 

|  |  |   Abbreviated Description 

|  |  | 

|  |  | 

|  |  Underscore 

|  Application Area 

| 

Custom development character indicator  

Length  12 Characters 

Development Standards 

Default „Terminate if rule resolution has no result‟. 

Description 

Short description of how the rule works and in which workflows it is used. 

Responsibility Naming Standards 

If Responsibility Rules are used then ensure that the responsibility has a meaningful name relating to thedata maintained for the responsibility. Please provide clear description of the Rule as it is visible as a helptext in OOCU_RESP for the users who will be maintaining these rules.  

 Also, it would be good to have Rules with Secondary Priorities so that a rule always results in an agent.Refer the following link for further details on Secondary Priorities: Defining Rules Using Responsibilities 

1.1.5. Re-evaluate Rules

When work is to be sent to a widening pool of users, e.g. as part of escalation, then the “Re-evaluate Rules of Active

Work Items” response should be use to implement this scenario. 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 11/13

This involves: 

a.  a) Assigning the original agents to the workflow step in a dynamic pool that can be updated, e.g. using a multiline

element of type TSWHACTOR  

 b.   b) Creating a specific event to trigger re-evaluation, e.g. object.REEVALUATE_AGENTS.

c.  c) This event should then be placed in the Basic Data of the workflow header in the Events section of the Version

Dependent section, using the “Re-evaluate Rules of Active Work Items” response. If the workflow contains nested

subflows, the event must be placed in the basic data of the workflow or subflow that contains the workflow step to

 be re-evaluated 

d.  d) In the steps following the relevant deadline reached outcome, the dynamic pool of agents to be assigned is

updated to add the additional agents, and the re-evaluate agents event is then raised using an Event Creator step  

1.1.6. Start Conditions

Start conditions are used for restricting the triggering a workflow to instances where certain conditions aremet. These (or check function modules for complicated evaluations) should be used rather than having acondition as the first step in a workflow. 

Exception to the above is when a condition involves evaluation of a parameter which gets populated inthe SAME LUW of the event trigger. Check function modules and Start conditions are always called in theSAME LUW of the event trigger. Chances are that the Start Condition/ Check FM get executed BEFOREthe parameter gets populated and the check condition does not evaluate correctly (example, reading

change documents for a particular value change). 

1.1.7. Terminating Events of Workflow

Workflows must always terminate when the workflow is no longer relevant, e.g. when the object isphysically or logically deleted, or changed to a status indicating it is no longer relevant, or a form iswithdrawn. If only termination of the workflow is required, then the terminating event should be specified in the BasicData of the workflow header in the Events section of the Version Dependent section, using the “Cancel Workflow” response. This simplifies flowchart design and maintenance. 

1.1.8. Subject Text Standards

To ensure the subject text is a useful sort criterion in the inbox, and to facilitate prompt understanding and

consequently actioning of the work required, standards will be applied to all subject texts for both workitems and emails as follows: 

  The first word will be the primary action type in Upper Case. This is used as the primary sort criterion. Forwork items this will be a current tense verb describing the action to be performed e.g. APPROVE,REVISE, CREATE, COMPLETE. For emails this will be a past tense verb describing the cause of theemail notification, e.g. APPROVED, REJECTED, OVERDUE. 

  The second word will be the primary business entity involved and either the id or name of the businessobject, e.g. Asset Laptop ABC, G/L account 123456 

  If any there is any capacity for additional text (subject texts are limited to approx. 50 characters in length)this can be used at the discretion of the business process  

Example of full subject texts: 

  APPROVE: Asset maint form 123456 from John Smith 

  APPROVED: Funds transfer 1234789 effective 18.03.2010 

1.1.9. Body Text Standards

To facilitate prompt understanding and consequently actioning of the work required, and to supportoccasional users, standards will be applied to all body texts for both work items and emails as follows: 

  Critical information for prioritizing work is listed first, e.g. Critical Date, Due Date 

  Brief (1-2 paragraphs) instructions for occasional users are then provided, particularly clarification of whatis required to complete the work and therefore remove the work item from the inbox  

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 12/13

  Reference to further instructions or policy documents can be provided as a text or hyperlink at thediscretion of the business (if hyperlink this will be implemented as an additional Action type= link tag usingUWL XML configuration) 

Body texts should be succinct. Ideally the complete body text should be able to be displayed in thePreview area when the Internet Browser Window is maximized without requiring the user to scroll throughthe text. 

1.1.10. Work Item Footers

 A standard support text such as “For  assistance in processing this workflow please contact XXXX”. Ifpracticable the text will be stored and maintained centrally, e.g. as a “General Text” maintained viatransaction SE61. 

1.1.11. Email Footers

To avoid unnecessary and ineffective email responses, all email notifications should contain a standardfooter text such as: 

“*** This email has been generated automatically. Please DO NOT REPLY. ***” The exact text is to be decided with the business. If practicable the text will be stored and maintainedcentrally, e.g. as a “General Text” maintained via transaction SE61. 

1.1.12. Workflow Related Function Modules

Function modules could be used in business object methods, Rule Resolution (when complicatedrequirements exist to determine an agent) or in Receiver Type and Check Function Modules. 

Rule, Receiver Type and Check function modules have to satisfy standard interface requirements to beable to work in the workflow environment. It is advisable to copy an existing standard function module toget this interface correct. 

Please refer to ABAP standards and procedures for function module naming standards. 

1.1.13. Development Class / Packages

 A development class or Package is a group of logically related development objects. A development classcontains all the development objects that must be developed, maintained, and transported together. Theobjects that make up a transaction usually belong to one development class. Customer developmentclasses begin with 'Y' or 'Z'.  

 A new development class for workflow ZWF1 should be used for all workflow developments. If not, pleasefollow the project development package guidelines. 

1.1.14. Transport Procedures

Transports are used to transfer development components from one system to another. The componentsto be transported are specified in the object list of a transport request. 

Please refer to basis standards and procedures for general transport procedures.  

For workflow developments it is recommended to transport in the following order  

1.  Workbench Requests: 1.  Related developments  – e.g. Development classes, Tables, Function Modules etc. 

2.  Business Objects 

3.  Workflow Templates, Standard Tasks, and Workflow Rules  

2.   Agent Assignments (ALWAYS include them in a TR - refer  http://scn.sap.com/docs/DOC-51922 ). 3.  Event linkages and activation 

It is recommended that in each target system the workflow test environment (SWUD) and consistencychecks are used to compile and check the workflows before use.  

1.1.15. Web Enabled Workflow

There are various techniques for linking a workflow step to a web screen. The inbox used will partiallydetermine the best approach. 

8/10/2019 WF Dev Standards

http://slidepdf.com/reader/full/wf-dev-standards 13/13

 

1.1.16. Portal

If the portal is used the Universal Worklist acts as the mechanism for launching the correct web screen.This is done through mapping the relevant task to the correct „Visualization‟ technique (iView, BSP etc.).To help generate this mapping correctly transaction SWFVISU should be maintained in the backendsystem. It should be noted that the mapping in the UWL overrides any settings in SWFVISU once this has

been initially generated. If custom iViews are called from the workflow then a Task with a Dummy Method will be required in thebackend (see section on methods above). The UWL automatically passes the Work Item Id when it callsan iView  – the iView will then need to retrieve information from the backend using a remote enabledfunction module  – this can then retrieve data from the workflow container. Once the user has successfullycompleted processing, the data can be set back to the container and the work item completed using therelevant WAPI calls (wrapped in an RFC Function module). 

Helpful links: SWFVISU 

Task Launch Customization 

Configure UWL 

UWL for WebDynpro Based Decisions 

UWL FAQ 

1.1.17. SAPGUI / E-Mail

If no Portal is used web services can be launched using the Web service Handler. If the web servicehandler is used it is also possible to build a URL to directly launch a service from an e-mail, although adummy user who is a possible agent will be required to complete the URL. 

1.1.18. E-Mail Connectivity

If E-mail Connectivity is required for a process this can be achieved in a number of ways, all of whichhave the pre-requisite that SAP Connect has been set up. Simple notifications can be sent from a workflow process using a Send Mail Step. E-Mail addressesshould never be „hard-configured‟ but should instead be derived from an expression. A good idea is touse TYPEID 'G' (Organizational Object) and the expression should be of type SWHACTOR (or multiple

TSWHACTOR), where SWHACTOR-OTYPE is 'US' and SWHACTOR-OBJID is the username. Thesystem will send a notification to the users SBWP inbox. To direct this mail to the user's email addressuse SO16 -> Tab Mail Sys. Group -> Select "Send to User's Home Address". The Workflow runtime willthen pick the email address from SU01 Master Data (if the Communication Method is set to INT - Internet)or the HR Communication Info type 0105. If both are maintained, anyone can be picked up by theworkflow runtime, the order is not specific.  

NOTE: SO16 settings have to be done in every system - DEV, QA and PRD.  

To inform users that they have new workflow items, e-mails can be sent using RSWUWFML2, or from6.40 onwards transaction SWNCONFIG can be used.