Business Scenario Using GP/Web Dynpro with Back and Forth 3 Level Process and Dynamic Approvers in a Loop

Transcription

1 Business Scenario Using GP/Web Dynpro with Back and Forth 3 Level Process and Dynamic Approvers in a Loop Applies to This Article applies to Guided Procedures, Web Dynpro Java, Business Process Modeling & Implementation, and Enterprise Portal 7.0. For more information, visit the Composition homepage. Summary This document describes about How to address a Real time Business Process (Price Negotiation) with Back and Forth steps and multiple approval levels through Business Process Modeling using Guided Procedures and implementing it using Web Dynpro Java. It also describes a workaround for a particular business scenario which cannot be addressed straight away using GP. This document could be a single point of reference on GP as it covers most of the aspects of Guided Procedures, GP Interface and also points to many other SDN blogs and articles wherever appropriate. Author: Ramesh Babu Kotagiri Company: Intelligroup Inc Created on: 05 March 2009 Author Bio Ramesh Babu Kotagiri is working as Senior Portal Consultant in Intelligroup. He has experience working on Web Dynpro Java, EP, CAF/GP, KM & C, Adobe Interactive Forms and PDK (Portal Development Kit). He had completed his Masters in Information Technology SAP AG 1

2 Table of Contents Process Modeling... 4 Initial GP Process Design & It s Limitations... 4 Solution and Improvisation to Initial GP Design... 5 Creation of Actual Process in GP Design Time... 6 References:... 6 Prerequisites & Dependencies for GP Interface... 7 Initiator Process Step... 9 Code in getdescription Method (Initiator Component)... 9 Code in Execute Method (Initiator Component) Code in Complete Method (Initiator Component) Approver-1 Process Step getdescription Method: Execute Method: Complete Method: Approver-2 Process Step Create Web Dynpro Applications Get Back to Creation of Actual Process in GP Design Time Create Callable Objects: Assigning Roles Dynamic User Assignment to the Roles at Runtime Consolidation or Parameter Mapping Running and Testing the GP Process for our Business Requirement Customizing the Task Names: Related Content Disclaimer and Liability Notice SAP AG 2

3 Introduction In one of my recent projects we have a workflow based business requirement which needs a solution to be accessed through SAP Enterprise Portal. Our Objective is to provide a workflow based solution in SAP Enterprise Portal for Price Negotiation. There will be a Price form (Adobe Interactive Form) which should be floated to and fro between Vendors (Initiators), First Level Managers and Second Level Managers (3 Level Process) for n number of times in a loop, until it is finally approved and on final approval should be updated to SAP R/3. To achieve this we will be modeling the Business Process using Guided Procedures and implementing the business logic in the form of callable objects using Web Dynpro Java which in turn uses SAP R/3 as data source. Business Scenario The Vendor Logs into Portal and by accessing a Portal Application selects the product and based on the product selection a Price Negotiation Form (Adobe Interactive) should be displayed with Initial data. The vendor will update the prices with new prices and submits the form. The First Level Manager and the Second Level Manager of that product is dynamically determined at run time and the form should be forwarded to the First Level Manager. The First Level Manager Logs into Portal and opens the pending task from his UWL inbox and will see the Adobe Interactive Form Submitted by the Vendor. He can accept the price quoted (Approve In this case depending on a business logic it may be either forwarded to Second Level Manager OR the first manager Approves (updates to SAP R/3) or Propose a new price and send the form back to Vendor (Reject). In a special case Second Level Manager may receive the form from the First Level Manager and he can also either approve or reject and send it back to Vendor. The Challenge Involved Using GP we can easily model this Business Process (Scenario explained above) if it is only progressive (i.e. only one way) or if there are only 2 Levels even if it is Back and Fro. But in our case we have 3 Levels and more over the process is bi-directional i.e. to and fro between the Vendor, Manager1 and Manager2. The vendor may receive the rejected form back either from First Level Manager or Second Level Manager, Manager-1 can either Approve the Form (Carry the data to next level) or Reject (Return the data to previous level) and on top of it this process should run in a loop for n number of times. For this we have to use a work around in our Process Model Design in GP Design Time and implement the IGPWeb DynproCO interface in our Web Dynpro Components accordingly SAP AG 3

4 Procedure Process Modeling Initial GP Process Design & It s Limitations As shown in the following diagram, with typical design, we can accomplish the work flow only one way i.e. a single cycle in forward direction. Each Block (Process Step) had one INPUT and one OUTPUT handle (In our case they are the structures defined using GP Interface in Web Dynpro Application which is explained in detail later, to make it simple for now, let s call them Input, Output handles) which can be used to pass data to the next step or receive data from the previous step. An INPUT handle can be mapped with only one OUTPUT handle and vice versa. With typical design as shown in the diagram, we can pass the data from Initiator Step to Manager1 Step (Line 1), carry forward the data from Manager1 Step to Manager2 Step (Line 2) and also return data from Manager2 Step to Initiator Step (Line 3). But can not return data from Manager1 Step to Initiator Step (Line 4 in red color) since the OUTPUT handle of Manager1 is already mapped to INPUT handle of Manager2. As per our requirement the OUTPUT of Manager1 can be either INPUT to Manager2 (in case he Approves) or can also be INPUT to Initiator (in case he Rejects). Note: There can be only a one to one mapping between an INPUT and OUTPUT SAP AG 4

5 Solution and Improvisation to Initial GP Design How to handle this limitation to address our requirement? All the examples and content I found in searching are describing the progressive approach i.e. from step1 to step 2 and then to step3, but I could not found any clues on how to handle back and forth scenario among 3 Process Steps. I desperately tried many ways and fortunately, found that we can define more than one INPUT and OUTPUT handles for a Process Step. Then changed the above design to fit our requirement as in the following diagram. This design approach addresses all the to and fro connections required among Initiator, Approver-1 and Approver-2. 1) The Initiator can submit the form (data) to Approver-1 (See Connection Line 1 in the bellow diagram) 2) Then Approver-1 can carry forward the Form (data) to Approver-2 for further Approval if required (this is determined by a business condition dynamically) (See Connection Line 2) 3) By now one cycle (in forward direction) had been addressed. What if the Approver-1 him self, Rejects the Form? Connection Line 3 in the diagram fulfills this by passing the form data back to Initiator. Hence Approver-1 can perform either of the 2 actions - Approve or Reject. When he Approves, the form data should be carry forwarded to next Level (Connection Line 2) and when he Rejects, the form data should be returned back to the Initiator (Connection Line 3). To have these two conditions in place, two OUTPUT handles were defined for Approver-1 step namely OUT-1 (mapped to IN-1 of Initiator, used to return data back when Rejected) and OUT-2 (mapped to IN of Approver-2, used to forward data to Approver-2 when Approved). 4) Another place where we need two handles is for the Initiator Step since the Initiator may receive the Form data either on Rejection of Approver-1 or Approver-2. In order to receive the data either from Approver-1 or Approver-2, we have accommodated two INPUT handles IN-1 (mapped to OUT-1 of Approver-1) and IN-2 (mapped to OUT of Approver-2) SAP AG 5

6 Creation of Actual Process in GP Design Time So far the approach to be followed in designing the Business Process using GP design time had been discussed and we finalized the approach to be followed (please refer to above diagram). In order to create a Process according to the above approach, in GP design time, we need to create a Process (TestPOCProcess) and then create 3 Parallel Blocks (Initiator Block, Approver1 Block, Approver2 Block) under the Process. There after create an action under each of these 3 Blocks Init Action under Initiator Block, Appr1 Action under Approver1 Block and Appr2 Action under Approver2 Block as shown in the following diagram. I am not describing the detailed steps for creating a Process, blocks, actions and callable objects using GP Design Time, as there is already very good content on this is available in SDN. References: For basic understanding of GP Design Time and creating a Process using Blocks, Actions and Callable Objects please refer to the following links SAP AG 6

7 Implementing the GP Interface through Web Dynpro After creating the 3 Actions for each Step (block), we have to associate each of these Actions with a callable object by creating a Callable Object of type Web Dynpro, under each Action. For creating a Callable Object we need to have an already deployed Web Dynpro Application. Hence before creating Callable Objects, we need to create 3 Web Dynpro components each for Initiator, Approver1 and Approver2 in a Development Component using NetWeaver Developer Studio. To simplify the UI and Code, I am using normal Web Dynpro UI instead of Adobe Interactive form and using only Value Nodes instead of RFCs and model nodes for the Price Update data. Prerequisites & Dependencies for GP Interface 1. CAF/GP installed 2. Assigned with GP Roles GP Administrator, GP Business Process Expert, GP Runtime To be able to call these Web Dynpro applications through GP callable objects, they should implement the GP Interface IGPWeb DynproCO. To implement this interface in a Web Dynpro DC, we should add some dependencies to our DC and components. 1. Create a DC Project in NWDS and create 3 Components Initiator, Approver1 and Approver2. 2. Navigate to the folder DC metadata/dc Definition/Used DCs and add the GP references (DCs) to your project by selecting the Add Used DC (right-mouse click). 3. Navigate to CAF in tree hierarchy and add the dependency caf/eu/gp/api/public Parts external, by checking the check boxes Design Time, Build Time and Run Time. 4. Similarly, add the dependency for caf/eu/gp/api/wd/public Parts - GPWeb DynproCO) 5. Right click on Project (DC), Choose Properties, Go to Web Dynpro References, Click on Library references tab and click add, Enter the library name caf/eu/gp/api and confirm SAP AG 7

8 6. After adding the above Dependencies you should see the marked Dependencies added under the Used DCs node which is under DC Meta Data node as shown in the below screenshot. 7. By completing the above mentioned steps we should be able to use GP Interface in our Web Dynpro Components. Check if the IGPWeb DynproCO is visible under the Implemented Interfaces of your Web Dynpro Component (Initiator Component in this case). 8. If you could not find the GP API in your NWDS, Down load it from the following link : m.cm.docs/business_packages/a1-8-4/gp_api_nw04s.zip 2009 SAP AG 8

9 Initiator Process Step Now the Interface Controller of our component (Initiator) will generate the skeleton for the 2 frame work methods GetDescription( ), Execute( ) and we have to define a custom method Complete( ) besides these two. I am only giving a very brief description of these methods. GetDescription Method :- Is used to define the INPUT and OUPUT structures (what we called Input and Output handles so far). Execute Method :- Is used to read the data from the INPUT structures (from the GP Framework) into our component s local Context. Complete Method :- Is used to transfer the manipulated data in the local Context of our Component, back to the OUTPUT structure (i.e. giving the data back to GP Framework). For Clear understanding of these methods and their functionality please refer the following link Code in getdescription Method (Initiator Component) Open the Interface Controller of the Initiator Component and you will find the method getdescription, whose skeleton is automatically generated by Web Dynpro. public com.sap.caf.eu.gp.co.api.igptechnicaldescription getdescription( java.util.locale locale ) { //@@begin getdescription() try { // Place the following code discussed, here } catch (GPInvocationException e) { msg.reportsuccess("u Got Exception at Get Description Initiator"+e); return null; } //@@end getdescription() } Note: We are using the normal approach for implementing the GP Interface which is already known to you, but observe how the structures (multiple) are defined to address our scenario and to be able to do proper mapping between them later in GP design time. Code in this method will be more or less same for the other two components Approver1 and Approver2 too, except the number of structures and structure names. Also Create the Context node and attributes in Component Controller and then do context mapping View To Component Controller, Component Controller to Interface Controller (both ways between them) SAP AG 9

10 //Get a reference to TextAccessor IWDTextAccessor textaccessor = wdcomponentapi.gettextaccessor(); //Get a reference to ResourceAccessor by passing textaccessor object reference to it GPWeb DynproResourceAccessor resourceaccessor = new GPWeb DynproResourceAccessor(textAccessor); //Obtain reference to TechnicalDescription IGPTechnicalDescription technicaldescription = GPCallableObjectFactory.createTechnicalDescription("Test POC", "Initiator Step",resourceAccessor,locale); // Now Define the Input Structure-1 (IN-1 in the diagram) which is used to // receive data from OUT-1 of Approver-1 When he rejects. //Input Structure-1 IGPStructureInfo input1 = technicaldescription.getinputstructureinfo(); //The name given here (poc requester Input1) will be shown in GP Design //Time while Mapping the Input and Output structures IGPStructureInfo PocInStruct1 = input1.addstructure("poc_reqi1"); PocInStruct1.setMultiplicity(IGPAttributeInfo.MULITIPLICITY_1_1); //Define attributes in the Input structure - 1 for Header data PocInStruct1.addAttribute("Addr", IGPAttributeInfo.BASE_STRING); PocInStruct1.addAttribute("Name", IGPAttributeInfo.BASE_STRING); PocInStruct1.addAttribute("ReceivedFrom", IGPAttributeInfo.BASE_STRING); // Exposing multiple Line Items is a bit different from using // Individual parameters i.e. header data. For more clarification on this // Please refer to the following blog by Dipankar. // // Define attributes in the Input structure - 1 for Line Items // Create another structure ItemList with Multiplicity 1 to N and add it // to the main Structure PocInStruct1 IGPStructureInfo InitLineItemsIn1 = PocInStruct1.addStructure("ItemsList"); InitLineItemsIn1.setMultiplicity(IGPStructureInfo.MULITIPLICITY_1_N); InitLineItemsIn1.addAttribute("ProductID", IGPAttributeInfo.BASE_STRING); InitLineItemsIn1.addAttribute("ProductDescr",IGPAttributeInfo.BASE_STRING); InitLineItemsIn1.addAttribute("Quantity", IGPAttributeInfo.BASE_STRING); // Similarly Define Input Structure -2 with the name poc_reqi2 which is used to Receive data from OUT of Approver-2 when he Rejects //Input Structure-2 IGPStructureInfo input2 = technicaldescription.getinputstructureinfo(); IGPStructureInfo PocInStruct2 = input2.addstructure("poc_reqi2"); PocInStruct2.setMultiplicity(IGPAttributeInfo.MULITIPLICITY_1_1); // Define Attributes in Input Structure - 2 for Header Data // Also Define only one Output Structure with the name poc_req0 which is used to pass // data to IN of Approver1 when the Initiator Submits the form. //Output Structure IGPStructureInfo output = technicaldescription.getoutputstructureinfo(); IGPStructureInfo PocOutStruct1 = output.addstructure("poc_reqo"); PocOutStruct1.setMultiplicity(IGPAttributeInfo.MULITIPLICITY_1_1); //Define attributes in the Output structure\parameters for Header Data // As the Last line of Code in getdescription method, Do not forget to Return this // technicaldescription object to GP Frame work return technicaldescription; 2009 SAP AG 10

11 Code in Execute Method (Initiator Component) Unlike the getdescription method which just defines the Input, Output structures and their attributes, the code in this method varies from component to component i.e from Initiator to Approver-1 etc. The catch here is there are two possibilities that the Initiator gets data 1. On Rejection of Approver1 2. On Rejection of Approver2 To avoid data overwriting (we have only one context and it should be filled with either Approver-1 data or Approver-2 data, but not both one after another. For example, say the form is rejected by Approver-1 and data is brought from Approver-1 step to Initiator, we have read it and stored in the context. Then if you don t take care the old data from Approver-2 will overwrite this data from Approver-1), we have taken an attribute in our Input Structures ReceivedFrom which is passed from Approver-1 and Approver-2 steps and we will track From where does the control came from, Is it Approver-1 or Approver-2, before reading the data. public void execute( com.sap.caf.eu.gp.co.api.igpexecutioncontextexecutioncontext ) { //@@begin execute() // Get the references of the IN-1 and IN-2 structures of this Initiator // Component, Read the data from GP framework and store in local context. this.executioncontext = executioncontext; IGPStructure input1 = executioncontext.getinputstructure(); IGPStructure inputstruct1 = input1.getstructure("poc_reqi1"); IGPStructure input2 = executioncontext.getinputstructure(); IGPStructure inputstruct2 = input2.getstructure("poc_reqi2"); String FromAppr1 = inputstruct1.getattributeasstring("receivedfrom"); String FromAppr2 = inputstruct2.getattributeasstring("receivedfrom"); If(FromAppr1 = true) //If it is from Approver-1 { // Set the input parameters (brought from Approver-1 Step) into the //context node String strname1 = inputstruct1.getattributeasstring("name"); wdcontext.currentcontextelement().setname(strname1); String straddr1 = inputstruct1.getattributeasstring("addr"); wdcontext.currentcontextelement().setaddr(straddr1); //Also Read and store the Line itmes Collection LineItemsStructList2 = inputstruct2.getstructures("itemslist"); for (Iterator iter = LineItemsStructList2.iterator(); iter.hasnext();) { IGPStructure LineItemsStruct2 = (IGPStructure) iter.next(); IWDNodeElement itemselement = wdcontext.nodevendorlineitems().createelement(); itemselement.setattributevalue("prodid",lineitemsstruct2.getattributeas String("ProductID")); itemselement.setattributevalue("proddescr",lineitemsstruct2.getattributeas String("ProductDescr")); itemselement.setattributevalue("prodqty",lineitemsstruct2.getattributeas String("Quantity")); wdcontext.nodevendorlineitems().addelement(itemselement); }//For }//If 2009 SAP AG 11

12 } If(FromAppr2 = true) // If it is from Approver-2 { // Set the input parameters (brought from Approver-2 Step) into the // context node just as shown in the above If block } //@@end of Execute Code in Complete Method (Initiator Component) In this method (Not generated by Framework and we have defined this as Custom method), we will push the data that we manipulated from our context into the GP Framework so that it will be available for the next process step or previous process step. public void complete( ) { //Get a reference to the OUT structure of this component IGPStructure output = executioncontext.getoutputstructure(); IGPStructure PocOutStruct = output.addstructure("poc_reqo"); //Read the Data from our Context and Push into OUT Structure PocOutStruct.setAttributeValue("Addr",wdContext.currentContextElement().getAddr()) ; PocOutStruct.setAttributeValue("Name",wdContext.currentContextElement().getName()) ; // Read Line Items and Expose to Next Level for(int i=0;i<wdcontext.nodevendorlineitems().size();i++) { IGPStructure itemslistinit = PocOutStruct.addStructure("ItemsList"); itemslistinit.setattributevalue("productid", wdcontext.nodevendorlineitems().getelementat(i).getattributevalue("prodid") ); itemslistinit.setattributevalue("productdescr", wdcontext.nodevendorlineitems().getelementat(i).getattributevalue("proddescr")); itemslistinit.setattributevalue("quantity", wdcontext.nodevendorlineitems().getelementat(i).getattributevalue("prodqty")); } // By calling this method, the current Process (Initiator in this case) ends and the // Control Returns back to GP Frame work. Then GP Framework determines the Next process // Step and directs the control there. executioncontext.processingcomplete(); msg.reportsuccess("form Submitted Successfully to the Approver"); } //End of Complete method Approver-1 Process Step By now we have completed the GP Implementation code for Initiator step (i.e. Initiator Component). Next we will be Creating another Component for the second process step Approver-1. If you check the Process Diagram above, we have 2 OUTPUT structures and 1 INPUT structure for this Step. Follow the same steps that we followed for creating the Initiator Component and Create another Component in our DC with the name Approver SAP AG 12

13 getdescription Method:- Open the Interface Controller of Approver1 Component and write the code in getdescription( ) method as follows: 1. Define one Input Structure with the name poc_reqi1 with same attributes as before. 2. Define two Output Structures poc_reqo1 and poc_reqo2 with same attributes as before Note: In addition to this, we have to add the following code (not there in Initiator step) to declare a ResultState as the Approver-1 has two actions Approve and Reject. This is used by the GP Frame Work in determining what is the target step for the actions Approve and Reject. // Add result states // Result State to track whether Approver-1 Approved the form or Rejected IGPCOResultStateInfo approvestatus = technicaldescription.addresultstate("approved"); approvestatus.setdescriptionkey("approved"); // Result State to track whether Approver-1 Rejected the form IGPCOResultStateInfo rejectstatus = technicaldescription.addresultstate("rejected"); rejectstatus.setdescriptionkey("rejected"); Execute Method: Read data from the input structure (brought from Initiator Step) and store into the context node and also the Line Items just as in Initiator Step. Complete Method: Read data from the Context and set it to Output Structure to make it available to next Process step just as in Initiator step. Note: But here we have to do an extra step as the Approver-1 can perform either of the two actions Approve or Reject and set the ResultState accordingly so that the GP Framework can check this. To do this let us add two action handlers in the view controller. public void onactionapproved(com.sap.tc.web Dynpro.progmodel.api.IWDCustomEvent wdevent ) { //@@begin onactionapproved(serverevent) wdthis.wdgetapprover1interfacecontroller().whenapproved(); //@@end } public void onactionrejected(com.sap.tc.web Dynpro.progmodel.api.IWDCustomEvent wdevent ) { //@@begin onactionrejected(serverevent) wdthis.wdgetapprover1interfacecontroller().whenrejected(); //@@end } And then create the corresponding Custom Methods in Interface Controller :- public void WhenApproved( ) { //@@begin WhenApproved() 2009 SAP AG 13

14 try { executioncontext.setresultstate("approved"); } catch (GPInvocationException e) { e.printstacktrace(); } wdthis.complete(); msg.reportsuccess("form Approved and Successfully forwarded to Second Approver"); //@@end } public void WhenRejected( ) { //@@begin WhenRejected() try { executioncontext.setresultstate("rejected"); } catch (GPInvocationException e) { // TODO Auto-generated catch block e.printstacktrace(); } wdthis.complete(); msg.reportsuccess("form Rejected and Successfully Returned to Initiator"); //@@end } Approver-2 Process Step For Approver-2 let us create another component by name Approver-2 and it is very similar to that of Approver-1 component except that it has only one INPUT and one OUTPUT structures. Create Web Dynpro Applications We have Completed the entire implementation of GP Interface and now create three Web Dynpro applications for each component Initiator, Approver1 and Approver2. Let us name the Applications InitiatorApp, Approver1App and Approver2App respectively and deploy them from NWDS. Get Back to Creation of Actual Process in GP Design Time We have already created the GP Process, 3 Blocks and 3 Actions already before. Please recall that we are still have to create 3 Callable Objects for these 3 Actions. By that time, since we don t have deployed Web Dynpro applications and hence we get into Web Dynpro. By now the Web Dynpro applications are deployed and we can proceed with creation of callable objects SAP AG 14

15 Create Callable Objects: Create Callable Objects (Under each Action) of Type Web Dynpro Component (GP Interface) under User Interface and select the corresponding Web Dynpro Application already deployed SAP AG 15

16 When you choose the Web Dynpro Component (Initiator in this case) and click on Next, GP Framework automatically recognized the INPUT and OUTPUT structures which we defined in Web Dynpro, as parameters here SAP AG 16

17 After Creating the 3 Callable Objects the GP Process Design should look like this. Change the Targets of the Result States, using the drop downs, as shown in the screen shot. Assigning Roles In GP Design Time, Select the Process and click on Default Roles Tab. Select each role from the drop down (Owner, Processor of Initiator Action, Processor of Approver1 Action, Processor of Approver2 Action, Administrator etc.) and assign your portal test users to them so that you will not be prompted to assign roles every time you run the process. For the test purpose I have assigned 3 test users each for Initiator, Approver1 and Approver2. Dynamic User Assignment to the Roles at Runtime In real time scenarios, it is seldom that we know the approvers in fore front. Even in our business scenario, The first Approver and Second Approver (Product Managers) are determined based on the Product the Initiator Selects in the form and submits. In this case, Instead of assigning the test users for all the Roles, in the design time (Under Default Roles Tab) itself, Just assign users, for only the Roles Overseer, Administrator and Owner since these roles are not dynamic and leave the rest of roles. The Roles Processor of Init Action, Processor of Approver1 Action, Processor of Approver2 Action should be dynamic and determined only at runtime. We need to maintain two Attributes in the Context for First Approver and Second Approver and we will fill these attributes with the User IDs of the approvers, from within the Web Dynpro Code using the business logic that determines who are the approvers SAP AG 17

18 Click on Roles Tab (instead of Default Roles) 1. Select each Role (ex: Processor of Init Action), Choose Runtime Defined from the Role Type Dropdown and Choose a Context Attribute (ex: FirstApprover, SecondApprover). 2. At runtime GP Framework will read the value of this Context Parameter which is a Portal User ID and forward the task to that user. Consolidation or Parameter Mapping While creating the callable object, GP recognized our INPUT and OUTPUT structures for each component or Process Step. Now, we should connect them to each other appropriately according to our predetermined approach (Refer the second Approach Diagram at the beginning). In other words we should join these input and output handles which is called as Consolidation of parameters. Select the Process and click on the Parameters Tab. You can see all the input output structure names we defined in all our 3 components (Refer the code for structure names). Select the corresponding two structures and Join them by clicking on Group button and giving a Group name. According to our Diagram we should map the handles (structures) as follows :- 1. Initiator OUT > Approver1 IN 2. Approver1 OUT > Approver2 IN 3. Approver1 OUT > Initiator IN-1 4. Approver2 OUT > Initiator IN-2 Note: To avoid confusion with the structures and to easily identify them, Please maintain proper naming (ex: poc_reqi1, poc_appr1o1 etc..). In the following diagram the display names are not properly maintained (The structure names we defined in Web Dynpro getdescription Method) and hence I am depending on the Defined for Column to identify them SAP AG 18

19 In order to create a mapping (for point number 1 above), Choose poc_reqo of Initiator Block, Hold Control and also Choose poc_reqi1 of Approver1 Block and then click on Group Button, Provide a group name (ex: Init OUT-- Appr1 IN) and click Create SAP AG 19

20 When you click on Create You can see the group now which contains the mappings of all the attributes of both these structures. Addr and Name are the Header data Parameters and itemslist is the sub structure. Note: This one to one mapping between independent parameters and also the sub structures (line items) is automatically done by the GP Framwork, provided the attribute and sub-structure names are same in both the main structures. Similarly create other Groups also and your final screen should look like this under Parameters tab once you are done SAP AG 20

21 Presenting the GP Process to the End User We are done with our GP Process design and Web Dynpro implementation of GP Interface and now the process is ready to run. For test purposes you can directly run the process from GP Run Time role by just choosing our Process Name and clicking on Start Process. But in a production Environment, the end users can not be given with GP Runtime Role and they can not run the process like this. Hence, we can present the GP Process as an iview on Portal to the End Users (like a link in the Navigation Area etc.) as in the below screen shot. To achieve this we have to create a Web Dynpro iview and maintain the GP Process URL in it s Application Parameters property. For detailed steps of this process, Please check the following Blog by Dipankar Saha. Running and Testing the GP Process for our Business Requirement 1. When the Vendor / Initiator (Portal User ) clicks on Vendor Price List link in Navigation Area under TestGP Role, the GP Process is automatically triggered and starts executing. Since the Callable Object of the Initiator Action is associated with the Initiator Web Dynpro Component, the GP Frame work calls that component and the user can see the Initiator View of that component SAP AG 21

22 2. To make the Process Simple, I am using the Web Dynpro UI here, In actual scenario, we have used Adobe Interactive Forms. 3. The First Approver (Portal User : ) logs into Portal, Founds Pending tasks in his GP Inbox and Clicks on the Link Tasks that require my action to see the Pending Tasks. For this test purpose, I am using the GP Runtime (assigned this role to all the 3 test users which is not appropriate in production environment) SAP AG 22

23 UWL Configuration to Receive GP Tasks 1. But in our actual business scenario these pending tasks should be available in Universal Work List of the Approvers. The UWL in Portal is used to receive Tasks, Alerts, and Notifications etc. from many sources besides GP. Hence, UWL is the right choice to show our workflow tasks also since it is a common In box for many other sources too, unlike the GP Runtime which only shows GP Tasks. To be able to get the tasks in to UWL, we should configure UWL for GP. For more details on how to configure UWL for GP, Please check the following link. If UWL is configured for GP, you will see the Tasks in UWL like in the following screen shot. These tasks are not related to our Process and this is just to show how the tasks are displayed in UWL. 2. On Clicking the Link Tasks that require my Action, the First Approver can see the list of Pending Tasks waiting for his action SAP AG 23

24 Customizing the Task Names: 1. By Default the Task is shown by the name of the Action (Appr1 Action) we defined while creating the Actions in GP Design Time. You can also customize these Task Names so that they show meaningful business names so that the approvers can easily identify from whom did he received this request. For a clear Understanding of how to get Dynamic Text instead of the Action Names in the UWL or GP Inbox, Please refer to this Blog:- b24bb5ec2b04 2. On clicking on the Task (Appr1 Action), the GP Framework calls the Approver1 Web Dynpro Component and the Approver1 View is visible to the First Approver (Portal user ). He can Approve or Reject. On Approve it may go to Second level approval or may end the process by updating to R/3. On Reject the form will be returned back to Initiator. 3. The Approver1 Action is completed and the control is returned back to GP framework from Web Dynpro. To demonstrate the complete workflow cycle, I am deliberately using the Second Approval also, but according to the requirement whether second approval is required or not is determined by some business logic SAP AG 24

25 4. Since the Action had been completed by Approver1, If he checks his Inbox now, the pending task will be removed from there. Recall that there are 2 Pending Tasks here earlier and now it is just one. 5. The Second Approver (Portal User ) Logs into Portal and checks his Inbox (GP Runtime) and founds there are pending Tasks waiting for his action. He Clicks on the Link Tasks that require my Action to see the list of Pending Tasks SAP AG 25

26 6. He can see there is a pending Task and clicks on it to open it. 7. The GP Framework calls the Approver2 Web Dynpro Component and the corresponding View with the data submitted by Approver1 is shown to the Second Approver SAP AG 26

27 8. On Click of the Reject Button, the Action gets completed and the control is returned back to GP Framework. Since in the design of the Process we defined that on Reject the next step is Initiator again, GP calls the Initiator Action again (Loop). 9. Since he (Second Approver ) had completed the pending action, now it should be cleared from his Inbox SAP AG 27

28 10. When the Initiator checks his Inbox, he will find a new Pending Task which he received back from Second Approver (100039) on Rejection. 11. Pending Tasks in Initiators Inbox SAP AG 28

29 12. The Initiator can see the data that is returned from Second Approver (on rejection). We can include comments field also for the Approvers and display it here, so that the Initiator understands the reason for rejection. 13. Now the Initiator will change the data in the form and resubmit it. It will be forwarded to First Approver again and the same workflow process explained above will be followed for N number of times in a loop until it is final approved. Once it is final approved, the form data is updated to R/3 and the process will end SAP AG 29

30 Conclusion I am fortunate to work with Dipankar Saha along with Balaji Bodagala, on GP using Web Dynpro about one and half years back, for other requirements, based on which Dipankar posted couple of Blogs then. Please check the links But in that case the number of approvers are not known in fore front and hence the process steps are dynamic. There is also a loop, but with only two process levels. The present scenario is completely different from that, with many additions like back and forth negotiations among 3 process levels etc. and hence I thought of presenting this article. I had pointed to many other SDN Links on GP for detailed steps, where ever appropriate, to avoid duplication of content and to make this article a single point of reference on GP. Using the above procedure we can create an end to end workflow based solution in Enterprise Portal using Guided Procedures for designing the Business Process and executing the Process, using Web Dynpro for implementing the GP Interface and creating components to be used by GP Callable Objects. I would appreciate if you have any thoughts on addressing the following aspects through GP. 1. Ability to use Substitute managers i.e. in the Absence of First approver the task should be automatically forwarded to some other user on behalf of him. I know there is a feature with UWL using which the manager can manually forward it to different user, But can this be automated. 2. If a task is in pending for a certain time out period with a manager, it should be automatically forwarded to some other manager. 3. If an approver assign some one else as substitute before his leave, all the tasks in his in box should also be visible to the substituted user who can complete the tasks, until the actual user comes back from leave. The left over tasks by the substitute user should be again visible to the actual user. If any one had worked on GP aspects like this, please share your ideas with me, by posting your comments on this Article SAP AG 30

31 Related Content All these links were already mentioned at various places of the document wherever appropriate. Here I am listing them once again altogether For more information, visit the Composition homepage SAP AG 31

32 Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document SAP AG 32