In this blog series I will outline how to use aBPM for your BPM processes to benefit from model driven user interface and persistence for BPM processes. I’ll start with the basic Excel based modelling and later show how to react on user events like buttons or search-helps with program code in callbacks.
Before we start just a quick overview of the requirements: You need an environment to develop SAP BPM processes. This contains at least a SAP Process Orchestration server and a NWDS (Netweaver Developer Studio) for modelling BPM processes and writing corresponding program code.
Beside some really simple demo cases you’ll also need a NWDI (Netweaver Development Infrastructure) to manage the sources as well as handling transports. aBPM is delivered in multiple SCA files that need to be placed into a development configuration on the NWDI server.
aBPM also needs multiple development components that contain the different artifacts like the BPM process itself, the Java sources and UME actions. The creation is described in the aBPM cookbook and will not part of this blog.
If this is set up, we can start developing…
Modelling the user interface
One of the major strengths of aBPM is the capability to model the user interface and persistence within an Excel sheet. The basic principle is to describe each attribute in a separate row in the sheet. There are multiple columns that contain e.g.:
- The technical name as a primary key of the attribute
- It’s long-, medium- and short-label name as well as a description field (for mouse over helps)
- The data-type (e.g. decimal, string, date or even currency)
- Optional default value and if necessary maximum and minimum values
- The UI element that should be used to present the attribute
- The segment and group to which the element belongs to (how to arrange UI elements in aBPM will be shown later)
- Multiple events the attribute can be listen to
- UI parameters that allow customization of the look and feel
For our example it looks like:
In order to use the Excel sheet as input for aBPM we export it as XML file. This is processes by an ANT script that checks the attributes and creates different Java, XSD, properties, … files that provide the data for the runtime part of aBPM:
- All setting from the Excel sheet will result in meta-data. The generated Java classes will update the database with the data during deployment of the scenario application
- aBPM also handles translation for all included artifacts and generates properties files for the defined target languages (the translation itself is supported by additional tooling but needs to be taken care of by the development team)
- XSD definition is created that can be used in the BPM process to exchange data between BPM and the JEE based UI logic
- UME actions that allow definition of multiple roles in the process
- Beside the meta-data the ANT script generates a frame where the custom code for handling events and the whole business logic needs to be placed
The execution of the ANT script looks like this:
The generated files are placed in 4 different DCs (BPM, UME, EJB and a WAR DC). The EJB and WAR DC will be deployed inside an EAR DC. After deploying all DCs the user interface as well as the persistence logic is in place and can be used:
Ok, that was really fast but it’s not yet complete. The next step is to define some action buttons that allow e.g. validation, saving the input and start of the process. This is done in an additional file, the config.xml file:
For defining buttons 2 sections are important: The “actions” area contain the definition of the buttons with its id (used to reference it inside the file), the command (used to identify it in the callback implementation) and title, tooltip and icon. In the section “action-configs” different configuration are defined that bundle the buttons that should be shown together. We use the default configuration “_START” that is used for the process creation application. It contains references to the buttons that it should contain.
After re-generating (with the ANT script) and re-deploying the EAR DC there are now buttons in the bottom located toolbar:
What’s still missing is the handling of events that are raised by clicking the buttons. This is done in the scenario-callback class. Initially it’s an empty class that is just extending a base class. We’ll override existing handler methods, in this case the handleUIEvent method that is called by all buttons from the user interface:
The aBPM specific implementation options with all provided methods are described in detail within the aBPM Cookbook. After this we can save the user inputs as well as start the associated BPM process. This looks like this:
After the start we can also have a look at the cockpit. This application is part of aBPM and allows displaying all details of existing aBPM processes including different search options (will be shown in detail within another blog). It allows us to see the just started aBPM process:
In the next blog I’ll show how to integrate aBPM as BPM instances…