In earlier parts of this series of blogs, we have learned to create a BPM Process, deploy it and import it in our Web Dynpro Java Component. This part focuses on the invocation of BPM process from our Web Dynpro Java application using java code. Sample code to invoke the adaptive web service model is given below:

 

ModelName objModelName = new ModelName();

 

Request_Name objRequest = new Request_Name(objModelName);

 

StartOpName objStartOpName = new StartOpName(objModelName);

 

// Set the values for the Details Node (Cardinality is 1:1)

DetailsType objDetailsType = new DetailsType(objModelName);

 

// Set the value for attribute Name, String type (Check for Null)

if (wdContext.currentDetailsElement().getName() != null)

objDetailsType.setName(wdContext.currentDetailsElement().getName());

else

objDetailsType.setName("");

 

// Set the value for Age (No check as by default it will be 0 if not already set)

objDetailsType.setName(wdContext.currentDetailsElement().getAge());

 

// Set the values for the Details Element

objStartOpName.setDetails(objDetailsType);

 

objRequest.setStartOp(objStartOpName);

 

// Bind the object

wdContext.nodeRequest_Name().bind(objRequest);

 

// Execute the model

wdContext.nodeRequest_Name().currentRequest_NameElement().modelObject().execute();

 

Above code is just for demonstration purpose and proper Naming/Coding standards should be followed while coding business applications. Remember we need to send the values for all the nodes which has a cardinality of 1:1 or 1:n failing which the model will throw errors and the process will not be triggered. Also verify that you do not send any null values for any string attributes, otherwise a null pointer exception will be thrown.

Part 1-4 of this series ‘Introduction to Netweaver BPM' were published in August 2009, since then I saw many requests coming from people on how to invoke the BPM Process from Web Dynpro Java. Part 5 will be focusing on how to import the Adaptive Web service model into a Web Dynpro development component whereas part 6 will be focusing on the code to invoke the web service using java code.   We will require the WSDL URL from WS Navigator for importing the model into our development component. For steps on how to get this are listed in Part 4 of this series available here  (Introduction to SAP Netweaver BPM: Part 4). Below are the steps to be followed in order to create the model by importing a WSDL directly from remote server:     *1. Navigate to Models in your Web Dynpro Component, right click and select ‘Create Model' from the context menu*    *2. From the Model Type popup that opens, select the ‘Adaptive Web Service Model' and press next*      *3. Give a model name and package and select ‘Remote Location / File System' option from Available WSDL sources*      *4. Paste the URL that we got from WS Navigator* 

I have seen so many people asking if this is possible in BPM to generate custom task names to be shown in UWL, so I though maybe I write a blog on this so that it will benefit people interested in learning BPM. This blog guides through the process of generating task (human activities) with a customized name by including values from the Process Context (such as Employee Name or a Request Id). Below is the step by step procedure on how to do this:

 

1. Open the task and navigate to User Texts as shown below

 

2. Click the Add button available on the Right side to add a variable

 

 

3. Rename the variable as required and then click on the Edit button available on Right to map it to context attribute (From where the value should come)

 

4. Follow steps 2 and 3 to add require variables

 

5. Now change the task name that should appear in the UWL by including the variables created above (Include them in curly brackets)

 

After completion of these steps, save-build and deploy the Process Composer project. Once you invoke the new deployed process, task should be generated with the customized names. Make sure that while mapping the variables, you should map the variable to the UIRequest since this will have the incoming data for the process context while UIResponse would be blank at the time task is created.

In this blog I will quickly talk about the custom KPI reporting solution that we implemented as part of a master data governance solution based on SAP MDM and BPM.

 

Initially while choosing the technology to implement the Master Data Governance solution at the client place we understood that BPM provides out of the box KPI functionalities (this was back in May 2009 when we started the implementation with CE 7.1.1)  which was one of the plus point for choosing the BPM + MDM combination.  Later on we realized that the process reporting is very minimal in the current release and would not serve the purpose of the clients Business requirements. So we proposed a custom application built in Web Dynpro Java which had strong request tracking and KPI reporting functionalities and it was accepted and implemented.

 

The solution captured the details of each request/approval step in the process along with other details that are required for the reporting purpose, additionally the solution captured the start and end time for each process step and calculated the total time taken to process a given request and then measured it against defined SLAs. Functionality of archiving request data (for SOX compliance) was also implemented for each request which can be retrieved at a later date in case of conflicts. For reporting purposes we also provided a facility to export the request into an excel sheet which may be downloaded and saved on client machine.

 

Below is the screenshot showing the custom KPI solution:

 

KPI Report

 

 

SLA violations were highlighted and total violation percentage was included for clear understanding of the business team. Till date the solution is very successful and we received a very positive feedback form the business. With much powerful reporting functionalities in CE 7.2, I think the new implementations can easily use the out of the box functionality provided by SAP, especially the ability to export to BW for reporting purposes would be very interesting and easy to use and it would definitely save the effort that we had put in implementing the custom solution.

Yesterday I went through a very interesting blog written by Ravi Kumar titled ‘Can we use SAP MDM for Central master data management?’ and that inspired me to write this blog. Here I would like to talk about a CMDM scenario which involved heterogeneous landscape including SAP MDM, SAP ECC 6.0 and SAP PI. We implemented a Master data governance solution for Customer Data maintenance which included Global as well as local attributes for the customer which included General Data, Controlling data and Sales Area Information for the Customer.

 

Since MDM workflows had several limitations as rightly highlighted in Ravi’s Blog, we chose the Netweaver BPM for implementing the Workflow functionality for various Customer Maintenance scenarios such as Create/Change/Extend & Block. BPM helped us to create a workflow that had:

 
  • Dynamic approvers based on various criteria (e.g., Process Based, Customer Type based, Sales Org based)
  • Ability to support Parallel Approval flows
  • Dynamic number of approval steps as required for different customers
  • Automated email notifications at each step of the approval process
  • Ability to measure KPI’s
  • Role based access to the applications
  • Flexibility for approvers to send back the request for correction
  • Request Tracking Mechanism
  • SLA Violation measurement
  • Request Archiving Functionality
  • Several other functionalities, the list goes on
 

In my humble opinion, SAP Netweaver BPM can almost solve all our workflow related limitations and whats more this has been the center of attraction for a while. With CE 7.2 coming out with much improved features, I am hoping that 7.3 would be even better J.

Having completed two end-to-end implementation projects for Customer Master and Vendor Master Data governance solutions using Netweaver BPM and Netweaver MDM in the last one year we were consistently getting different requiremnts for the Workflow solution. Different type of users laid emphasis on different things and it was a herculean task to satisfy all the requirements, so we made some tradeoffs and arrived at the final solution which more or less satisfied the ‘critical' needs for all the users. Below are some of the requireents that came up from different type of users:

 

End Users: These were the users from the field force of the customer organization and had very little to nil technical knowledge. Their main concern was the availability of the solution over the PDA/Smartphone/Blackberry, reason given was that they are always carrying mobiles and it will be very user friendly and they do not necessarily have their notebooks connected to internet every time or while travelling. We had to turn down the request citing the technical feasibility as BPM is currently not supported on mobile devices.

 

Master Data Stewards: Master Data Steward team that owned this solution wanted that all the requests should be archived and the data processed in a particular request should be permanently stored somewhere physically or in electronic document format. Initially we did not plan anything in this regard but later we proposed a solution for generating PDFs for each request and storing it.

 

SOX Compliance Team: SOX Team came up with several requirements for additional controls to restrict the access and track the changes done to that data. On of the major thing that they wanted to get implemented was to maintain a log of changes at all levels in a process (If we have four approval steps along with one request step, then they wanted that one PDF is generated and stored at each step). Maintaining such a huge volume of data for requests would have been a nightmare and so we agreed for a more logical solution by mutual agreement.

 

Business Users: Business wanted the master data to be created as early as possible and if they were given a choice, they would have removed all the approval steps from the workflow and would have loved to create the data directly without any approvals.

 

Management: For management, the most important information coming out from this implementation was a way to measure the Key Performance Indicators. Management wanted to measure the KPIs against agreed SLAs to identify and remove bottlenecks, run improvement programs and make proper decisions. We proposed a customised KPI reporting solution to the client which had request tracking, comprehensive search capabilities and reporting features.

 

We arrived at a consensus by clearly showing the tradeoffs in cost vs benefit and we simply left requirements that were 'Nice to have' and not critical to the business.