SAP ABAP Workflows Day 2

SAP ABAP Workflow
Workflow Template
©La rsen & Toubro Infotech Ltd. Privileged and Confidential 2

Workflow Templates
▪ The workflow templates are models, which you can copy and then adjust to represent your own
processes in the workflow.
▪ It is a design time version of the workflow. Whereas workflow instance is the run time version of the
workflow.

Workflow Step Types
▪ Container Operation
▪ Used for calculation with the help of workflow containers

Workflow Step Types
▪ Activity
▪ Business process / task to be executed
▪ E.g. Approval of purchase order
▪ Standard Task / Customer Task

Workflow Step Types
▪ Condition
▪ A single condition check with two outcomes (True/False)
▪ Multiple Condition
▪ Multiple condition checks with multiple outcomes (Case / Switch)

Workflow Step Types
▪ Loop
▪ Repeat the workflow steps till the condition is satisfied
▪ Fork
▪ Used when parallel processing is required which may or may not be based on any condition

Workflow Step Types
▪ Process Control
▪ Cancel Work item

Specify the node number of the step that is to be cancelled
On execution status of the corresponding work item is set to logically deleted
▪ Cancel Workflow
All the work items of the workflow are set to logically deleted
▪ Set Work-Item to Obsolete
Used in the branch of modeled deadline monitoring
Work item is set to completed at the time of step execution
▪ Complete Workflow
Work items are set to status completed
▪ Cancel workflow (Including all callers)
If this step is in the sub workflow then the work items of sub workflow as well as of calling
workflow are set to logically deleted

Workflow Step Types
▪ Wait
This step is used when we to wait for an event to happen or a condition to get satisfied so that we can proceed
further in workflow
▪ Wait for condition –
This step is complete when the specified condition is satisfied
▪ Wait for local event
Stops the execution of branch till the specified local event has occurred
▪ Wait for event
Stops the execution of the branch until the defined event of a particular object occurs
If event arrives it completes all the steps that are waiting for this event
▪ Wait for event using workflow
In this case an event can complete only one step. In case of multiple wait steps for the same
event, it completes the oldest wait step

Workflow Step Types
▪ Event Creator
▪ To implement a BO event or a local event after the workflow has started
▪ Document from template

▪ Enables creation of documents in workflow with different PC application (e.g. Excel)
▪ Template can refer to elements from the container
▪ On execution document is saved in container element in workflow container
▪ Form
▪ To display the container elements at the time of execution
▪ Allows editing of the values in elements
▪ Local Workflow
▪ Model the part of the workflow that is started by local event

2
Workflow Tasks

Workflow Tasks
▪ A task can be defined as an activity that can be executed within a workflow definition or
independently.
▪ Background Task
▪ Refers to automatically executable methods
▪ Does not require any user intervention for execution
▪ E.g. Email Sending Method, Automatic PO creation
▪ Dialog Task
▪ Requires user intervention for the execution of task
▪ E.g. Approval of leave, Approval of Shopping Cart

Workflow Tasks
▪ Basic Types:
▪ Single Step Task
▪ Task can be part of workflow definition as a step of type activity
▪ Multiple Step Task
▪ Activity defined by workflow definition
▪ Standard task (TS)

▪ Single-Step task
▪ Cross Client
▪ Customer task (T)

▪ Single-step task
▪ Client Specific
▪ Workflow template (WS)

▪ Multistep task
▪ Cross Client
▪ Workflow task (WF)

▪ Multistep task
▪ Client Specific
▪ Task group (TG)
▪ Collection of Standard Task, Workflow Template and other task groups.
3
Agent Determination

Agent Determination
▪ Agent is a person/user who can execute the task
▪ Types of agents
▪ Possible Agents
▪ People who can execute the task
▪ Defined at the task level
▪ This is the pool of agents that will be considered later to become an agent of the work item
▪ Responsible Agents
▪ People who are supposed to execute a particular work item
▪ Assigned at workflow step level (Can be assigned at task level too)
▪ These are determined at run time by using expressions or rules
▪ In expressions – agent data should be stored in container elements
▪ In rules – agent data is dynamically determined
▪ A Responsible agent can only process a work item if they are a possible agent and if they are not an
excluded agent.

Agent Determination
▪ Types of agents
▪ Excluded Agents
▪ People who should not receive the work item for execution
▪ Always assigned by expression in workflow step
▪ Cannot be an agent of the task even if they are listed as a responsible and/or selected agent

Agent Determination
The Selected Agents of the work item will be the ones that are
at the intersection of the Possible Agents and Responsible
Agents and are NOT included in the intersection of Excluded
Agents
This woman is in the pool of Possible Agents but she is not one
of the Responsible Agents so she will not be able to process
the work item.
This man is in the pool of Possible Agents and he is in the pool

of Responsible Agents; however, he is also on the list of
excluded agents so he will not be able to process the work
item.
Agent Determination
▪ Agent Assignment
▪ Agent Assignment at the Workflow step level
▪ In case an agent is assigned at workflow step level then it’s a responsible agents.
▪ Agent can be assigned as a User, Role, Job etc.
▪ Further an agent id can be determined and stored in workflow container element and the container element
is assigned as expression in agents

Agent Determination
▪ Agent Assignment
▪ Agent Assignment at the task level
▪ Possible agents assignment

Agent Determination
▪ Possible Agent Assignment

▪ When assigning possible agents you can choose different task types:
▪ General task : Can be seen by all users, no further restriction possible
▪ General forwarding allowed (default): Can be restricted by user, role, job etc. and can also be
forwarded between users
General forwarding not allowed: Can be restricted by user, role, job etc. but can't be forwarded
▪
between users
▪ Other options available within this dialog are:
▪ Locked for instantiation -Stops workflow from running
▪ Locked against execution -Allows workflow to run but when user tries to execute items they do not
processed assigned functionality, simply move from inbox to outbox

4
Workflow Rules

Workflow Rules
▪ A Rule is a general way to 'define' your agents.

▪ A rule is maintained with Transaction code PFAC and is used to
programmatically define the agents.
▪ For example, if you want a work item to go to all managers who worked for the
company for 5 years or more, then you would have to create a rule that
handles this custom scenario. Typically this is done by creating a custom
function module that performs your selection logic and passes the results back
to the rule.
▪ You can define a container element that contains the object of Organizational
Management at runtime or a rule for dynamic agent determination.
▪ Transactions:
– PFAC_INS (Create).
– PFAC_CHG (Change).
– PFAC_DIS (Display).
– PFAC_DEL (Delete).

Workflow Rules
▪ Each rule gets a 8 digit generated by the system prefixed with AC

▪ Rules can be tested using PFAC or by function module ‘RH_GET_ACTORS’.
▪ Rule Container
– The rule container contains a rule’s parameters.
– Each rule has just one rule container.
– At runtime, the rule parameters contain the current, context-specific information that
forms the basis of rule resolution. Therefore, the rule parameters constitute "input" for
rule resolution.
– In SAP Business Workflow, binding feeds the rule parameters with values from the
workflow container. If a task contains default rules, the system fills the rule container
from the task container using binding.
– If a rule is used in a workflow to determine the responsible agent, the result of rule
resolution is stored in the container element _RULE_RESULT and can be transferred to
the workflow container by binding.
▪ If an error occurs during rule resolution, setting the termination indicator for the
rule resolution determines how the workflow will continue
▪ If the indicator is selected - the workflow assumes an Error status and a
notification is sent to the workflow administrator
▪ Indicator is not active - the workflow forwards this work item to ALL possible
▪ agents. ©La rsen & Toubro Infotech Ltd. Privileged and Confidential 23
Workflow Rules
▪ Rule Resolution :
The following types of Rules can be resolved:
▪ Agent determination rules :

– Agent determination rule is used in SAP Business Workflow for example, determine
the responsible agents of a work item who have certain characteristics.
▪ Web Flow Rules :

– Web Flow rules are used within a workflow in the basic data and in the Web activity
step type.
– Using a Web Flow rule you can individually execute the following parts of a Web
activity:
• Determination of URL
• Preparation of the XML document
• Determination of the authentication data
• Execution of the send procedure
• Determination of transfer format

Workflow Rules
▪ Agent Determination Rule Types:

– Responsibilities (pure configuration, no ABAP code)
• Defined value ranges are assigned to agents
• Data is filled from the workflow container at runtime
– Organizational data (pure configuration, no ABAP code)
• SAP Organizational Object Types are used to assign agents
– Function to be executed
• ABAP code
• You can develop each function module required yourself
– Organizational attributes
• You can use organizational attributes in the SAP applications EBP and
CRM.
▪ Essentially, there are 4 types of rules that you can use in the Activity step type.
▪ The rule using organizational attributes is not used in the SAP R/3 component.
▪ Three of the four rules only require system settings; for the fourth solution, a customer-
specific function module must be defined in the system.
Workflow Rules - Using Function to Be Executed
▪ Defining Rules Using Function to Be Executed

▪ You use function modules for defining agent determination rules when very
complex selection criteria, which cannot be depicted by other rule categories,
are required for agent determination.
▪ The function module must enable the following process:

– The rule container transferred as the table parameter AC_CONTAINER is read using
the macro commands SWC_GET_ELEMENT and SWC_GET_TABLE. Note: If you
want to have the macro commands available, you must integrate the Include
<CNTN01> as a sub-report for shared use. <CNTN01> mainly contains the macro
command definitions for creating and processing a container instance.
– The rule parameters are used to determine the responsible agent(s). At its simplest,
this sub-program consists of a loop on a (Customizing) table, from which the agent
is selected.
– The table ACTOR_TAB is filled.

▪ The rules can be created or changed using the standard SAP transaction
PFAC. Once the rules are created you can call these rules in any workflow via
the rule container.
▪ Scenario: Create a rule which will find the superior for any user/agent.
▪ Design:
▪ Create a custom table ZTEST_USERS which will contain the names, positions
of each user along with their superiors’ name.

▪ Create a custom function module ZTEST_FIND_SUPERIOR which will return

back the table containing all the superior information for a particular
user/agent.
▪ This custom function module created should have the same interface as that of
the SAP standard function module RH_GET_ACTORS.
▪ The following table’s parameters have to exist in the custom function module.
– ACTOR_TAB STRUCTURE SWHACTOR
– AC_CONTAINER STRUCTURE SWCONT

▪ Source Code:
FUNCTION ZTEST_FIND_SUPERIOR.
*"--------------------------------------------------------------------
*"*"Local Interface:
*" TABLES
*" ACTOR_TAB STRUCTURE SWHACTOR
*" AC_CONTAINER STRUCTURE SWCONT
*" EXCEPTIONS
*" NOBODY_FOUND
*"--------------------------------------------------------------------
INCLUDE <cntn01>.
TYPES : BEGIN OF ty_users.

INCLUDE STRUCTURE ztest_users.
TYPES : END OF ty_users.
DATA: org_agent LIKE wfsyst-agent,

lt_holders TYPE STANDARD TABLE OF swhactor,
lwa_holders TYPE swhactor,
lt_users TYPE STANDARD TABLE OF ty_users,
lwa_users TYPE ty_users,
v_len TYPE i,
v_bname LIKE ztest_users-bname,
num_lines TYPE i.
* Read values assigned to the rule criteria

swc_get_element ac_container 'org_agent' org_agent.
* Get the superior

SELECT SINGLE *
FROM ztest_users
INTO CORRESPONDING FIELDS OF lwa_users
WHERE bname = org_agent.
IF NOT lwa_users IS INITIAL.

REFRESH lt_holders[].
lwa_holders-otype = 'US'.
lwa_holders-objid = lwa_users-zsuperior.
APPEND lwa_holders TO lt_holders.
APPEND LINES OF lt_holders TO actor_tab.
ENDIF.
DESCRIBE TABLE actor_tab LINES num_lines.

IF num_lines IS INITIAL.
RAISE nobody_found.
ENDIF.
ENDFUNCTION.

▪ Exception- Go to the exception tab of the Custom Function Module and enter
the exceptions as required. Here we have added the Exception
NOBODY_FOUND.
▪ Now we have created the Function module ZTEST_FIND_SUPERIOR. We will

now assign this Function module on the Rule.
▪ Go to transaction PFAC to create rule. Create rule ZRULE_TEST.

In the Rule Definition tab select the Agent Determination: Function to be

Executed in the Category field and provide the name of the Function module
created (ZTEST_FIND_SUPERIOR).
▪ Go to the Container tab and create a container element for the agent/user
which will be passed to the function module by clicking the Create Button and
enter the values as shown.

▪ Container element is added as shown below

▪ The rule is now created and we can test this rule in the PFAC transaction by
clicking the “Simulation” button on the application toolbar. Enter the user
name in the Container Element value section and press enter.

▪ It displays the name of the superior for the agent/user and the Agent Found is
displayed in Green color.

• Now we can use this rule in any of your workflow definition as

required.

Workflow Rules - Responsibilities
▪ Rule Category Agent Determination: Responsibilities

▪ With this rule category you can select agents based on values from the
workflow or the task. To do this, you transfer container elements from the task
or workflow container to the rule container using binding. In the rule you define
responsibilities that relate Organizational Management objects (job, position,
organizational unit, user, and so on) with possible values from container
elements in the rule container.
▪ A responsibility is itself an organizational object that requires no Customizing
settings and no ABAP source text.
▪ Defined Value ranges are assigned to Agents.
▪ Data is filled from workflow container at runtime.

▪ Procedure:
▪ Go to PFAC_ INS/PFAC_CHG transaction for create/change rule.
▪ On the Rule Definition tab page, choose the category Agent Determination:
Responsibilities, and assign an abbreviation and a name for the rule.

▪ Create Rule Container
▪ The Rule Container must contain the container elements whose values you
want the system to check when the rule is executed. At runtime, binding fills
the rule container with data from the task or workflow container.
▪ To create the rule container, you therefore need to know the definition of the
task or workflow container.
▪ Go to the Container tab and Choose.
▪ The Create container element dialog box appears. Make entries in the
Element, Name, and Short Description fields.
▪ Create either an object reference or an ABAP dictionary reference for the
container element.
▪ As a guide, you can use the data type reference of the container element of
the workflow or task container from which the container will be filled at runtime.

▪ Create Rule Container

▪ On the Properties tab page, set, if required, the Obligatory and/or Multiline
indicators.
▪ Repeat steps 1 to 4 until you have defined all the necessary elements for the
rule container.
▪ Creating a Responsibility
▪ With a responsibility you define the container element values that you want to
trigger processing by the same users. In the responsibility, you define values or
value ranges for the container elements of the rule container. If you wish, you
can assign a priority to each responsibility.
▪ Go to the Responsibilities tab. Choose.

▪ The Create Responsibility dialog box appears.

▪ Enter an abbreviation, a name, and the validity period of the responsibility and confirm
your entries.
▪ The Change Responsibility for Rule <.....> screen appears.

▪ In this responsibility editor, all container elements in the rule container are listed.

▪ Enter a single value or a value range for the container elements whose content
you want the system to check during rule resolution. If you want to check
several single values or value ranges for one container element, you can
create new entry rows.
▪ Position the cursor in a row with the container element for which you need a
new row, and choose
▪ Note:
– If you do not want to check a container element for a particular responsibility,
leave this line blank. The status of the responsibility is set to Responsibility
incomplete, in order to draw your attention to unchecked container elements.
– If you wish, give the responsibility a priority.
– The responsibilities with the highest priority are evaluated first.
Responsibilities with lower priorities are only evaluated if this is defined in the
rule definition.

▪ Enter a single value or a value range for the container elements whose content
you want the system to check during rule resolution. If you want to check
several single values or value ranges for one container element, you can
create new entry rows.
▪ Position the cursor in a row with the container element for which you need a
new row, and choose
▪ Note:
– If you do not want to check a container element for a particular responsibility,
leave this line blank. The status of the responsibility is set to Responsibility
incomplete, in order to draw your attention to unchecked container elements.
– If you wish, give the responsibility a priority.
– The responsibilities with the highest priority are evaluated first.
Responsibilities with lower priorities are only evaluated if this is defined in the
rule definition.

▪ Enter a single value or a value range for the container elements whose content you want
the system to check during rule resolution. If you want to check several single values or
value ranges for one container element, you can create new entry rows.
▪ Position the cursor in a row with the container element for which you need a new row,
and choose
▪ Save it.
Note:
• If you do not want to check a
container element for a particular
responsibility, leave this line blank.
The status of the responsibility is set
to Responsibility incomplete, in order
to draw your attention to unchecked
container elements.
• If you wish, give the responsibility a
priority.
• The responsibilities with the highest
priority are evaluated first.
Responsibilities with lower priorities
are only evaluated if this is defined
in the rule definition.

▪ 5. Assigning Users or Organizational Objects to the Responsibility

▪ You assign Organizational Management objects to a responsibility. These are
then returned as the result of the rule, if the responsibility check is positive.
▪ In the Responsibility tab select the responsibility to which you want to assign
an Organizational Management object, and choose.
▪ The Selection dialog box appears.

▪ Select an object type

that you want to
assign as an agent
and choose Continue.
▪ The system asks you
to enter a search term
and to create the
relationship between
the responsibility and
the selected object.
Confirm your entries.
▪ In the Overall View,
you can also specify a
validity period for the
relationship.

5
Deadline Monitoring

Deadline monitoring
▪ Deadline monitoring defines the time span with in which a job is

scheduled to End. If the task is not executed within the specified time,
Escalation happens. The particular work item is terminated and the
subsequent step (Mail) is executed.
▪ E.g. If you are designing a workflow and the requirement is that a particular
Task, for example approval of employee’s leave request should be
completed by the manager within a given time frame then we can set a
deadline for the task. Once the deadline is reached, we can then apply
further logic using escalation functionality in order to escalate the approval
task(work) to their superior manager or any other agent/user as required by
the process.

Deadline monitoring
▪ Following are different deadlines that can be monitored against each workflow
step:
– Requested Start
– Latest Start
– Requested End
– Latest End
▪ These can be defined at Workflow Step Level

Deadline monitoring
▪ Requested Start
– This is Earliest point in time at which the work item can be executed.
– E.g. Even if the employee submits their travel request to the manager, the
company policy requires that a 2 days waiting period is required before the
manager can actually approve the request.
– A dialog work item (approver task) appears in the Business Workplace of the
manager when the requested start is reached if the work item is already available
for processing.
– If the dialog work item is not created until after the requested start, it appears
immediately in the Business Workplaces of its recipients.
– With background work items, execution starts when the requested start is reached
at the earliest.
▪ Latest Start
– Deadline by which one of the recipients of a work item must have started to
process it.
– E.g. If the employee submits their performance appraisal then it is required that the
manager should START reviewing the appraisal document within a certain period of
time.
Deadline monitoring
▪ Requested End
– Deadline by which the processing of a work item should be terminated.
– E.g. In the above case of performance appraisal, the appraisal approval by
manager should complete within a given time period.
▪ Latest End
– Latest point in time for the processing of a work item to end
▪ In all practical cases Requested End and Latest End behave the same way, just that
if a user opens a work item ( Reserves the work item ) then the Requested End date
deadline will not kick in. Only the Latest End date will be valid. Hence usually its is
advisable to set Latest End greater than Requested End.
▪ E.g. In case of performance appraisal, the appraisal approval by manager should

completed within a given time period greater that requested end otherwise the
appraisal will escalate to higher manager

Deadline monitoring
Date/Time Specification for Deadline:

• Work item Creation : Here you specify the time within which work item
should be executed after its creation

Deadline monitoring
• Workflow Creation: Here you specify the time within which work item
should be executed after the creation of the workflow
• Expression: Here you can specify the date and time when the work item
should be executed. Container elements can be used to hold the date/time.

Deadline monitoring
▪ Deadline Monitoring - Escalation

– We can define an action to be executed once the deadline is reached.
– Following Action types can be defined:
– Display Text
• In this an escalation work item with text is created and sent to another
User/Group of users
• E.g. If the leave approval task is not completed then send escalation
message to the approver’s superior
– Modeled
• In this case a local workflow event can be triggered which in turn may
execute a series of steps
Deadline monitoring
▪ Deadline Monitoring - Escalation

– Modeled
• In this case a local workflow event can be triggered which in turn may
execute a series of steps

6
Programming exits

Programming exits
▪ Program exits are like user exits given by SAP in SAP Workflows which can
be used to tweak standard workflow functionalities. Program exits are the
hooks given in SAP Workflows where we can execute additional methods
that are programmed when predefined events occur.
▪ Exit technology enables user-defined reporting/logging.
▪ Programmed response to the start and end of a workflow
▪ Programmed response to any change in the status of a work item
▪ Exit technology allows workflow designer to save data to their own tables at
set times while the workflow data is executed. You can then use this data to
create an application-specific reporting function based on unrestricted
application-related data, rather than on the technical status of the workflow
system.

Programming exits
▪ Application Specific Reporting

Programming exits
▪ The Technology Behind Work Item Exits

▪ The exit is created as an ABAP class which implements a predefined
interface.
▪ In the workflow step:
▪ The exit class is entered.
▪ Parameters are set for the exit class with constants ("Properties").
▪ The entire workflow context is available when you call the exit class at
runtime.
▪ A user-defined reporting program evaluates the data written in the exit.
▪ A programming exit is an ABAP class that implements the interface
IF_SWF_IFS_WORKITEM_EXIT.
▪ The relevant exit class must be entered in the modelling (Workflow Builder)
for each of the workflow steps that you want to call for the exit. At this step
you can also enter parameters for the call (.Properties.) with constant
values. The names of the properties must be globally unambiguous. The
prefix .sap.bc.bmt.wfm. reserved for the SAP Workflow system.

Programming exits
▪ Time-line for the programming exit

Programming exits
▪ The exit class is called by the Work Item Manager (WIM) every time the status of the
work item is changed. When this happens, it receives the time (symbolic name) and the
work item context as parameters.
▪ You can also use the context object to query the following:
– The values of the properties saved in the step at the definition time
– The entire work item header
– The workflow container and the container of the current work item
▪ The exit class evaluates this information and fills a database specifically created for this
purpose (Reporting or User status table).
▪ While the workflow is being executed, you can read the status table using a user-defined
report.
▪ Currently the interface IF_SWF_IFS_WORKITEM_EXIT contains one method
▪ only: "event_raised". This method is called by the workflow system every time the status
is changed. Therefore, it must internally separate the possible calling times and respond
appropriately to each required time (for example, by calling a suitable private method).
▪ See the class CL_SWH_WORKITEM_EXIT. as a sample implementation.
▪ The parameter IM_EVENT_NAME contains the time when the exit class is
▪ currently called. Symbolic constants for all possible times are contained in the type pool
SWRCO.

Programming exits
▪ The parameter IM_WORKITEM_CONTEXT contains a work item context object

▪ that can be used to determine and implement the work item header and work
item container. The following selection of query methods is available:
– GET_HEADER (get work item header)
– GET_PROPERTY (query a property defined in the step)
– GET_RULE_RESULT (query result of the rule resolution)
– GET_STATE_TRANSITION (query current status transition (source and
– target status)
– GET_TASK_ID (query task ID)
– GET_WF_CONTAINER (query workflow container)
– GET_WF_CONTAINER (query work item container)

Programming exits - Example
▪ Below scenario explains the use of Program Exits in SAP Workflows to tweak
the SAP Work item functionality without making major changes at workflow
level.
▪ We are taking example of Journal Entry workflow which is triggered when
accounting document is parked.
▪ In Example Journal Entry workflow, the work items are sent to designated
approvers for approval for posting. Based on approval limits, the work items are
sent either for approval or for forwarding. Issue was that the work items were
moving out of the inbox, allowing the approver to approve even though
document was kept opened by another user, which was not correct. The
requirement was to stop the user from approving the work item if document was
being edited by another user and throw an error message.
▪ Pre-requisite:
▪ Custom ABAP classes are required to be put in program exit tab of SAP
Workflows.
▪ The ABAP Class used in program exits must support the interface
IF_SWF_IFS_WORKITEM_EXIT and this class must not have any call to the
RFC function modules also there shouldn't be any commit or roll back
statements in it. ©La rsen & Toubro Infotech Ltd. Privileged and Confidential 66
▪ In Example Journal Entry Workflow, there is a decision step for approval as

shown below:
▪ In Order to control the work items sent through decision steps above, we
introduced program exits in both the decision steps. For program exits, we
need to create ABAP Class

▪ ABAP Class Creation:

▪ The ABAP Class should support the interface IF_SWF_IFS_WORKITEM_EXIT.
The properties of ABAP Class should be as shown in screen shot below:

▪ Add interface IF_SWF_IFS_WORKITEM_EXIT in the interface tab.
▪ The Attributes corresponding to standard interface are automatically populated in

Attributes tab. An additional attribute WI_CONTEXT is added to get the current context of
work items.
▪ Method IF_SWF_IFS_WORKITEM_EXIT~EVENT_RAISED is created automatically. Two
additional methods AFTER_CREATION and AFTER_EXECUTION are added to handle
predefined events of work items as shown in below screen shot:

▪ Implementation of Method EVENT_RAISED:

The main logic for throwing error and restricting work item from moving out of inbox if
document is opened by another user is written in this method.




SAP ABAP Workflows Day 2

Uploaded by

Copyright:

Available Formats

You might also like

SAP ABAP Workflows Day 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP ABAP Workflows Day 2

Uploaded by

Copyright:

Available Formats

SAP ABAP Workflow

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 2

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 3

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 4

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 5

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 6

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 7

▪ Cancel Work item

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 8

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 9

▪ Document from template

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 10

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 11

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 12

▪ Standard task (TS)

▪ Customer task (T)

▪ Workflow template (WS)

▪ Workflow task (WF)

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 14

▪ Agent is a person/user who can execute the task

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 15

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 16

This man is in the pool of Possible Agents and he is in the pool

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 18

▪ Possible agents assignment

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 19

▪ Possible Agent Assignment

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 20

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 21

▪ A Rule is a general way to 'define' your agents.

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 22

▪ Each rule gets a 8 digit generated by the system prefixed with AC

▪ Agent determination rules :

▪ Web Flow Rules :

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 24

▪ Agent Determination Rule Types:

▪ Defining Rules Using Function to Be Executed

▪ The function module must enable the following process:

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 26

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 27

▪ Create a custom function module ZTEST_FIND_SUPERIOR which will return

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 28

TYPES : BEGIN OF ty_users.

DATA: org_agent LIKE wfsyst-agent,

* Read values assigned to the rule criteria

* Get the superior

IF NOT lwa_users IS INITIAL.

DESCRIBE TABLE actor_tab LINES num_lines.

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 30

▪ Now we have created the Function module ZTEST_FIND_SUPERIOR. We will

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 31

In the Rule Definition tab select the Agent Determination: Function to be

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 33

▪ Container element is added as shown below

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 34

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 35

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 36

• Now we can use this rule in any of your workflow definition as

©La rsen & Toubro Infotech Ltd. Privileged and Confidential 37