In the first four parts of this series we had a look on:
This time we’ll have a look at the aBPM cockpit.
One common requirement of customers is that they would like to
Based on these requirements aBPM provides the cockpit application. It’s a UI5 based viewer of existing processes with form and other process data. The processes can be filtered by generic (e.g. date) or scenario specific filters. The start screen looks like:
At the top of the screen you can see the filter area with the generic and scenario specific filters. Also it includes a collection of predefined combination of selection criteria named as “Search Parameters”. We’ll come back on this later on in this blog. It’s also possible to search via Id of the process, the user or begin and end date. If you restrict the selection on one scenario the filter will add scenario specific filter fields (if available). We’ll go into this also later on.
Below the filter area you’ll find a table with the selected processes. It contains all aBPM modelled BPM processes that matches the criteria. Beside the description, the functional Id, status, user and the starting date you’ll also see additional information. This field contains supplementary information about the process, in the given example some processes maintain the information about the state they are in. aBPM supports receiving the current state of the BPM process by providing methods in the callback interface that are triggered by BPMs JMS events (https://help.sap.com/viewer/6fc9ea54f6d3425183718b944038b882/7.5.9/en-US/4e263c830b92495c90415cc59de...).
The toolbox at the bottom contains button to open the form (depending on the state in read-only or editable mode) or the details of the current selected form. The details contain multiple views:
At the bottom of the screen you can see that the toolbox buttons also have changed. Now the following buttons are visible:
At the end of this overview you can see that aBPM’s cockpit is one central view of current running processes that allows inside in the form data as well as process execution. It’s also possible to cancel the process from there or use existing process forms as templates for new processes.
If you followed my blog series about aBPM you are not surprised that the cockpit can be adapted to your needs. As usual this is done via a callback interface that is implemented in Java.
As the cockpit is used by all scenarios at the same time, it’s not integrated into the scenario interface but has one of its own: It’s called ICockpitCallbackLocal:
As you can see it’s a simple interface with 2 methods:
Technically this is an interface defining a session EJB. If you need to adapt the default behavior (as usual, aBPM contains a basic implementation of the interface) you need to build an session bean that implements the interface and register it in the system properties (NWA) at the key “cockpit.callback.name” with its JNDI key.
The class that is used for both methods is SearchFilter. It contains information that help to manipulate the cockpit appearance. Some examples are:
As already mentioned it is possible to specify additional filter parameters for a certain scenario. These will only be shown if the user restricts the shown scenarios:
As this is a scenario specific feature it’s configured in the scenario callback implementation. The following steps are necessary:
The ISearchInformationProvider contains 4 methods, the getSearchFields defines additional search/filter fields that are added in the cockpit.
The other fields aren’t necessary for the cockpit filter and handle the display state for the standalone display application and the enable/disable state of the cancel button mentioned at the beginning of this blog.
The returned list of SearchField objects contains the necessary information for this, a possible simple implementation of this method – that adds one additional search field for a filed with technical name “CompCode” – could look like:
Although this example is working properly it is missing translation and other aspects that are necessary for a real-live usage.
The last step to integrate the filter fields is to return the custom implementation in the queryInterface method of the scenario callback. The code for this looks like:
This blog gives an introduction of the aBPM cockpit and how it can be adopted to your needs. I showed some extension points that allow setting of default values, definition of predefined filter scenarios and additional, scenario specific filter fields.
- the definition/design of the user interface (https://blogs.sap.com/2016/09/08/abpm-step-by-step/),
- the integration of aBPM with SAP BPM workflows (https://blogs.sap.com/2016/09/25/abpm-step-by-step-part-2/),
- the enhancements for emails (https://blogs.sap.com/2017/05/05/abpm-step-by-step-part-3/)
- and the PDF generation with aBPM (https://blogs.sap.com/2017/12/27/abpm-step-by-step-part-4/).
This time we’ll have a look at the aBPM cockpit.
What is the aBPM cockpit?
One common requirement of customers is that they would like to
- view the form of the current running processes independent if an active is assigned to them, even of even finished processes
- provide the capability to search in the process data
- …
Based on these requirements aBPM provides the cockpit application. It’s a UI5 based viewer of existing processes with form and other process data. The processes can be filtered by generic (e.g. date) or scenario specific filters. The start screen looks like:
At the top of the screen you can see the filter area with the generic and scenario specific filters. Also it includes a collection of predefined combination of selection criteria named as “Search Parameters”. We’ll come back on this later on in this blog. It’s also possible to search via Id of the process, the user or begin and end date. If you restrict the selection on one scenario the filter will add scenario specific filter fields (if available). We’ll go into this also later on.
Below the filter area you’ll find a table with the selected processes. It contains all aBPM modelled BPM processes that matches the criteria. Beside the description, the functional Id, status, user and the starting date you’ll also see additional information. This field contains supplementary information about the process, in the given example some processes maintain the information about the state they are in. aBPM supports receiving the current state of the BPM process by providing methods in the callback interface that are triggered by BPMs JMS events (https://help.sap.com/viewer/6fc9ea54f6d3425183718b944038b882/7.5.9/en-US/4e263c830b92495c90415cc59de...).
The toolbox at the bottom contains button to open the form (depending on the state in read-only or editable mode) or the details of the current selected form. The details contain multiple views:
- Details – This is an extended view of the data also shown in the table. On desktop environment it contains also a link to BPMs graphical process view (as this is in flash you can’t use it on iOS and so we disabled it on tablets and phones)
- Tasks – Contain a list of tasks that were created and completed for the given BPM process. It allows you to see the process history.
- History – aBPM offers the creation of versions of the from data. It can be configured per scenario and allows tracking of changes. Inside the detail view of the cockpit you can see at which times the form was saved and what changes on the form data were done.
- Feeds – Displays all feed messages for the given process. The feeds view in the cockpit is one way to work with aBPM feeds feature that allows sharing and discussing information about the process outside of the form itself. I’ll present the logic and usage later in a different blog.
- Children – The last view contains the “children” of the selected process. “Children” are aBPM modelled processes that are triggered at a certain time in the parent. They are different than BPMs sub-processes because from BPMs point of view they are separate BPM processes but aBPM contains logic to connect parent with its children. I’ll also present the logic and usage later in a different blog.
At the bottom of the screen you can see that the toolbox buttons also have changed. Now the following buttons are visible:
- Cancel – If you follow aBPMs modelling guide you can make use of cancelling processes. As usual you can influence via callback interface if the button is enabled. Technically the BPM process is waiting in an intermediate event if it should cancel itself. By clicking this button you would send the signal.
- Delete draft – If you start entering data and don’t start a process, the form is saved by aBPM in state “draft”. This allows you to stop entering data without losing the already filled data.
- Use as template – You can use the given process data to start a new process and avoid entering all data from scratch. If you trigger “use as template” aBPM will copy the data to a fresh from and saves you time and effort. Not all data is copied because it wouldn’t be useful to copy data that is filled later in the process, aBPM allows modifying the copied data during copy process by a callback.
At the end of this overview you can see that aBPM’s cockpit is one central view of current running processes that allows inside in the form data as well as process execution. It’s also possible to cancel the process from there or use existing process forms as templates for new processes.
Adapting the cockpit
If you followed my blog series about aBPM you are not surprised that the cockpit can be adapted to your needs. As usual this is done via a callback interface that is implemented in Java.
Cockpit callback
As the cockpit is used by all scenarios at the same time, it’s not integrated into the scenario interface but has one of its own: It’s called ICockpitCallbackLocal:
package com.sap.consulting.abpm.core.bl.cockpit;
import java.util.Locale;
import java.util.ResourceBundle;
import javax.ejb.Local;
import com.sap.consulting.abpm.core.bl.service.SearchFilter;
@Local
public interface ICockpitCallbackLocal {
/**
* initialize the search is used when opening the search UI. The callback delivers a SearchFilter.
* Entrys from the Search filter are used to populate the UI
*/
SearchFilter initSearch(SearchFilter searchFilter, Locale locale, ResourceBundle resourceBundle);
/**
* prepare search is used just before the search is done to make sure the search filter is filled
* correctly. Especially the list with the scenarioSearchParams
*/
SearchFilter prepareSearch(SearchFilter searchFilter);
}
As you can see it’s a simple interface with 2 methods:
- initSearch – allow initializing the UI filters
- search – is called before the search and computing of the search results is done.
Technically this is an interface defining a session EJB. If you need to adapt the default behavior (as usual, aBPM contains a basic implementation of the interface) you need to build an session bean that implements the interface and register it in the system properties (NWA) at the key “cockpit.callback.name” with its JNDI key.
The class that is used for both methods is SearchFilter. It contains information that help to manipulate the cockpit appearance. Some examples are:
- Maximum processes returned from the search
- A list of Search Parameters from which the user can select predefined search criterias
- Values for dates to be used as prefilled values
- …
SearchInformationProvider
As already mentioned it is possible to specify additional filter parameters for a certain scenario. These will only be shown if the user restricts the shown scenarios:
As this is a scenario specific feature it’s configured in the scenario callback implementation. The following steps are necessary:
- Implement the interface ISearchInformationProvider with a custom class for your scenario.
- Return this in the queryInterface method in your scenario callback.
The ISearchInformationProvider contains 4 methods, the getSearchFields defines additional search/filter fields that are added in the cockpit.
package com.sap.consulting.abpm.core.bl.callback;
import java.util.List;
import java.util.Locale;
public interface ISearchInformationProvider {
enum CallingLocation { COCKPIT, FORM };
/**
*
* @param localization
* @return
*/
List<SearchField> getSearchFields(Locale localization);
/**
*
* @param ctx
* @return
*/
String getDisplayState(CallbackContext ctx);
/**
*
* @return
*/
String getDisplayCompanyCode();
/**
*
* @param process
* @param location
* @return
*/
boolean isCancelable(CallbackContext ctx, CallingLocation location);
}
The other fields aren’t necessary for the cockpit filter and handle the display state for the standalone display application and the enable/disable state of the cancel button mentioned at the beginning of this blog.
The returned list of SearchField objects contains the necessary information for this, a possible simple implementation of this method – that adds one additional search field for a filed with technical name “CompCode” – could look like:
@Override
public List<SearchField> getSearchFields(Locale localization) {
List<SearchField> result = new ArrayList<SearchField>();
CoreUIService cuis = ServiceLocator.getBOService();
BusinessObjectMetaData bomd = cuis.findBusinessObjectMetaDataByTechnicalName("bo://com.sap.consulting.abpm.demo.sandbox.bo/Sandbox");
for (AttributeMetaData amd : bomd.getAttributeMetaData()) {
SearchField sf = new SearchField();
if ("CompCode".equalsIgnoreCase(amd.getTechnicalName())) {
sf.setAttributeMetaData(amd);
sf.setDefaultValue("T0");
sf.setDescription("Search");
sf.setForSearch(true);
}
else {
continue;
}
result.add(sf);
}
return result;
}
Although this example is working properly it is missing translation and other aspects that are necessary for a real-live usage.
The last step to integrate the filter fields is to return the custom implementation in the queryInterface method of the scenario callback. The code for this looks like:
@Override
public Object queryInterface(AbstractWrappedCallbackContext<Sandbox> ctx, InterfaceType type) {
if (InterfaceType.ISearchInformationProvider.equals(type)) {
return new SearchInformationProvider();
}
// handling of different interface-types
return super.queryInterface(ctx, type);
}
Summary
This blog gives an introduction of the aBPM cockpit and how it can be adopted to your needs. I showed some extension points that allow setting of default values, definition of predefined filter scenarios and additional, scenario specific filter fields.
- SAP Managed Tags:
