SAP NetWeaver BPM is used for implementation of complex business processes that generate a lot of business data while execution. This data is used both for decision making while execution and for the analysis of the business processes. The business process may involve and interact with SAP and third party systems (non-SAP Systems). A use case on reporting options to business users on BPM process will be discussed in this BLOG. Reporting can be achieved by using Reporting Data Sources (will be referred as RDS) or Java Persistence Architecture (will be referred as JPA). This paper will describe the best practice on when to use RDS or JPA.
SAP Provides BPM API for RDS-based search to retrieve information about the reporting data sources deployed in the system. You can then query the information and enable the search for process instances based on the process context data stored in the RDS. The BPM Reporting API provides the business users the facility to monitor process instances with no knowledge of the BPM concepts. This leads to the decrease of the administrative support.
One of the possible specific use cases could be as follows: the business process of interest is governance of Customer Master Data that involves SAP and non- SAP Systems. The data about the Customers, its replication time-stamps to SAP and non- SAP Systems. (E.g. The name the customer, account groups, replication time-stamps of data to and from between multiple systems in the landscape and many other pertinent attributes) are stored in the RDS. Using the BPM Reporting API, one is able to identify the relevant process instances and its status given the name of the customer, customer id or the date of the customer creation or updation. A complex process may have multiple flow objects, and the process may have to paused, resumed based on certain business requirements. To get the exact status of the process, RDS has to be added to at each and every step. This means RDS has to be added before and after the flow objects. RDS provided by SAP is capable of handling the inserts only. At every step during the execution of process, a structure of data gets inserted into RDS. This structure of data and the mapping between process context and RDS has to be defined in the design time of process. The major disadvantage of using RDS is, it does not have a concept of Primary Key or Unique identifier that identifies the structure of data. This means it allows multiple inserts with no Update facility. Reporting done on RDS will result in multiple records for a single process instance. Thus the report developed on RDS will fetch multiple records based on the status of the process instance. The records thus shown on the report will resemble a log like facility for the process instance. Business users don’t find this to be effective for business reporting.
The best approach for reporting on BPM is using JPA. JPA provides both inserts and updates facility on an entity referred as temporary table that’s get created in the database. A Web service has to be created for CRUD operations on the JPA entity. The ability to perform CRUD operations gives better control for business reporting. An automated activity referring the web service has to be added before and after the flow objects. Reporting done on the JPA entity for a particular process instance will fetch a single record. This record shows the exact status of the process instance. Also the memory usage on the table is optimal, which will ultimately fetch better performance and accurate business reporting unlike RDS where a record gets inserted for every step that might cause memory issues.
Bluesky
