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…
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.:
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:
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…
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
21 | |
16 | |
13 | |
12 | |
11 | |
10 | |
7 | |
7 | |
7 | |
7 |