Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member4529
Active Contributor
0 Kudos

Guided Procedure is a very effective tool for developing workflow processes in cross-applications environment. In enterprise business workflow processes we have multiple approval steps often where the process steps are dynamic and repetitive and the processor (approvers) are determined at runtime based on business conditions like requestor's business unit or type of business transactions, etc. In this document let's take an example where an employee of an organization raises a cash reimbursement request. Before the request is created in SAP ERP backend it needs to be approved by the manager of the employee. But based on the amount requested and the position of the employee the approval steps may increase or decrease and the approvers are selected dynamically based on the requestor's HR hierarchy. E.g. if an employee of grade 1 raises a request of $1000 then 3 levels of manager's approval is required as only a manager of grade 3 can approve a request of $1000. That means 3 levels of dynamic steps will be created at runtime (in a loop) and the processor of those actions will also be assigned at runtime based on the HR hierarchy of the employee.

Developing the User Interfaces
The user interfaces for the GP process are developed using Web Dynpro Java callable object implementing GP interface. To create a Web Dynpro Java callable object we need to implement a GP interface available in some standard DC provided by SAP. For more details how to create the Web Dynpro Java callable object please refer the following documents/weblogs:

  1. Implementing a Web Dynpro Callable Object which Implements the GP Interface
  2. Implementing a Web Dynpro Callable Object
  3. How to Get NW04s SP7 Guided Procedure APIs for Local Development
  4. Working with the APIs of CAF Guided Procedures: NWDI or Local Development?

Create two Web Dynpro components implementing the GP interface - one for requestor and another for approver. In both the Web Dynpro component define the GP callable object's attribute structure as below:

Name Type Cardinality
CRR_Request Structure 0...1
amount Decimal 0...1
businessTransaction String 0...1
companyCode String 0...1
costCenter String 0...1
requestDate Date 0...1
username String 0...1
totalApprovalLevels Integer 0...1
currentApprovalLevel Integer 0...1
nextApprover String 0...1
ApproverList Structure 0...n
approvalLevel Integer 0...1
approverID String 0...1

These definitions should be present in the getDescription() method of both the Web Dynpro components. In the execute() method of the Interface Controller of the Request component you need not write any code except one line to hold the IGPExecutionContext object as below.
this.executionContext = executionContext;
In the complete() method populate the GP callable object's output structure as defined in getDescription() method. Here the approval levels and the approvers' user id are determined by calling a RFC in SAP ECC. In our example we take three approval levels. The approval levels and the approvers are populated in the ApproverList table of the GP callable object's output structure. As we have three approval levels we have three rows in the ApproverList table. Also set the totalApprovalLevels, currentApprovalLevel and nextApprover attributes present in the CRR_Request structure. The currentApprovalLevel attribute value should be 0 as we are in the Request component i.e. no approval has been done. This attribute value should be incremented by 1 in the Approval component for each step. The nextApprover attribute value should be the first approver's user id. And the totalApprovalLevels attribute value should be the total levels of approval required i.e. in this case 3.

In the next component i.e. the Approver component in the execute() method of the Interface controller read the GP callable object's input structure as defined in getDescription() method. While reading the currentApprovalLevel attribute under CRR_Request increament its value by 1 and save it in the Web Dynpro context node attribute. Also read the ApproverList table and assign the nextApprover attribute value as well as below: wdContext.currentApprovalDetailsElement().setCurrentLevel(crrInitForm.getAttributeAsInt("currentApprovalLevel")+1);
Collection approvalItemList = crrInitForm.getStructures("ApproverList");
for (Iterator iter = approvalItemList.iterator(); iter.hasNext();)
{
IGPStructure approvalStruct = (IGPStructure) iter.next();
IWDNodeElement approvalElement = wdContext.nodeApprovalList().createElement();
approvalElement.setAttributeValue("approvalLevel", new Integer(approvalStruct.getAttributeAsInt("approvalLevel")));
approvalElement.setAttributeValue("userID", approvalStruct.getAttributeAsString("approverID"));
wdContext.nodeApprovalList().addElement(approvalElement);
}
if(wdContext.currentApprovalDetailsElement().getCurrentLevel()<crrInitForm.getAttributeAsInt("totalApprovalLevels")) { wdContext.currentApprovalDetailsElement().setNextApprover((String)wdContext.nodeApprovalList().getElementAt(crrInitForm.getAttributeAsInt("currentApprovalLevel")+1).getAttributeValue("userID"));
}

In the above code the nextApprover is picked from the ApproverList based on the currentApprovalLevel.

In the complete() method assign all the attribute values to the GP context attribute.

Developing the GP Process
For this process we need two Web Dynpro callable objects - one for the requestor and another for the approver. The approver Web Dynpro callable object will be used in a loop for multiple approval steps.

First create a sequential block consisting of the Web Dynpro callable object for the requestor under the process.

Then add a pre-conditional loop block consisting of the approval callable object in a loop body block. The pre-conditional loop block must have a decision action to control the looping.

The first action created under the loop block automatically becomes a decision action. We need a decision callable object to determine the looping step and number of loops executed. Decision actions can be either user executed or in background. For user executed decision action we can use the decision dialog. But as here we need to determine the looping step in background we’ll use a Business Logic callable object. Create a Business Logic callable object present under Process Control category as shown below:



Add two input parameters - currentLevel and totalLevels (type unsigned integer). These two variables will determine whether we need to loop or stop. totalLevels variable holds the total number of approval steps required and currentLevel variable holds the current approval level. Both the variables will be set from the initial (requestor) action and the currentLevel variable will be updated at each approval step.



Now in the next step create two resultstates for the Business Logic callable object. The resultstates' names should be always continue and break (in small case). And these resultstates won't be shown in the corresponding decision action. In the Expression specify the condition to break or continue in the loop block. Here in this example we'll break when the current approval level exceeds the total level of approval required.

Add a Loop Body Block under the Precondition Loop Block. Select the Precondition Loop Block and select Loop Body Block from the drop-down and click on New as shown in the diagram below.



In the pop-up screen select Sequential Block and click Select.



Create an action under the Loop-Body block and add the Web Dynpro callable object for approval under it. Actions for rejections mails Also another sequential block can be added under the process after the Approval Block as Request Approved, which will be processed when the request is approved to send a notification or do posting at the backend. Now the process will look as below.

Parameter Mapping
Now we need to do the parameter grouping. Select the process as it's the parent level to all the blocks and open the Parameters tab. First group the totalApprovalLevels attribute from the first callable object's output structure to the Business Logic callable object's (CheckLevel) input as below:

Next group the currentApprovalLevel attribute from the first callable object's output structure to the Business Logic callable object's input structure as below:

Note that the currentApprovalLevel attribute value of the Business Logic callable object should be equal to the Request callable object's output structure's attribute value for the first time. But while in the loop for approval action the value should be equal to the Approval callable object's output structure's attribute value. We'll take care of that later.

Next group the output structure and input and output structure of the Request and Approval callable object together.

Now the parameter mapping at the process level will look as below:

Now we need to group the currentApprovalLevel attribute (from Approval CO to Business Logic CO). For that select the conditional loop block and open the parameters tab. Select currentApprovalLevel attribute of the Approval callable object's output parameter and the same attribute of the Business Logic callable object's input parameter and group them as below:

Dynamic Processor Assignment
The processor for the Approval component should be assigned dynamically as given by the nextApprover attribute value. Select loop body block (sequential block - Approver Request) under the conditional loop block and open the Roles tab. Check the checkbox "Filled From Context Parameter" beside Processor of Approver Request and a drop-down appears beside it. Select CRR_Request->nextApprover as below:

This will dynamically assign the nextApprover attribute value (which is changed to the approver at the next level in the Approver component) to the Approve Request action.
Now select the process and open the Roles tab. Select Processor of Create Request action as Initiator i.e. whoever starts the process will do the first action (create request). Also assign the built-in roles to the initiator or Administrator. Save and activate the process. This completes the process design. Now you can create an iview to start the process which can be integrated into the Enterprise Portal. Refer How To Present Your GP Processes To The End User for same.

Running The Process
As the process design and implementation is complete now we'll run the process. Login to Enterprise Portal with the user to whom the iview is assigned. Click on the iview link to start the process. The Request component's callable object (Web Dynpro view) is displayed. Enter the details as required.

The Check Approver button when clicked calls a RFC from SAP ECC and retrieves the approver details based on the amount and employee grade of the requestor as displayed in the table. Now the user clicks on Submit to send the request.



As shown above the next approver is displayed as the processor of the next action (first level approval) based on the approver list.

Now the first approver logs in to Enterprise Portal and find a task in his UWL as below:



When clicks on the UWL task it opens the GP process with the approver's view.



Here the approver can approver or reject the request. If rejected a mail is sent to the requestor and the process stops. If approved then it goes to the next level of approval.



Similarly if the second approver approves the request then it goes to the third and final level.

Here all the approvers are assigned dynamically based on the data returned by the first/request action. And the Business Logic callable object determines the number of repetitions based on the current approval level (which is incremented every time in the approval action) and the total approval levels.

This way business processes having multiple dynamic steps and user assignment at run-time can be designed using Guided Procedure.

65 Comments
Labels in this area