SOA Magazine IV 01.2015

Custom BPM Library – BpmLib
Looking in more detail to the BpmLib component, it is a java library that is responsible for all the calls to
the BPM API, and returning our custom data types, creating an abstraction layer over the BPM API. It
also has other functions like caching and preprocessing data for the ADF interface generation.
Creating an abstraction layer has all the normal advantages, and in our case have helped us to expose
custom methods in the way we needed them in order to achieve our final goal. The API is very powerful,
allowing all kinds of interactions with the underlying engines. But since we only needed a subset of
those functionalities that meant that there were many options in the API that we didn’t need. We used
the BpmLib to hide those options, for instance when querying processes and tasks the API allows us to
define which columns we want to be returned. This library "hides" that functionality and always returns
the same columns. Another example is the use of flex fields on human tasks. Since we return our own
custom made classes we already include in them the business data that’s stored in the flex fields so that
the upper layers don’t have to be concerned with the origin of the data. Using our own classes also
allows us to flatten the class structure, simplifying access to the other fields.
Instantiating the service objects of the API is a heavy operation and as such we cache those objects.
However this raises a problem, this library is running on a different managed server than the SOA and
BPM Suite. When the SOA managed server is restarted, the connection becomes invalid, and all calls to
the API throw a javax.ejb.EJBException. We had to include a mechanism to catch those exceptions and
invalidate the service cache. On the other hand, since all managed servers are clustered, we did not
need to account for unavailability of the SOA managed server. Given that in the case of unavailability of
the SOA managed server most of the functionality would be unavailable anyway, that was not a
requirement.
Other cached data is the security contexts of the users. Users are authenticated by the ADF
infrastructure, but with that information we then need to create the security contexts that the BPM API
uses. Since this creation is also a heavy operation we cache these contexts. However we had to be
careful to not create vulnerabilities that would allow a user to use the cached context of another. We
also had to invalidate each entry regularly to allow new security definitions, like group and role
membership changes, to be picked up.
Regarding the automatic generation of human tasks interface, this library is responsible for fetching and
preprocessing the payload of the tasks so that ADF layers can generate the interface.
On the BPM side we define the task payload using not only the base XSD types like string and date, but
also other custom types, ranging from generic types like text to indicate to the interface generator that
the field should be rendered has a text area, to other, more business specific types, like account, which
the generator knows how they have to be rendered. This also includes types that have to be rendered as
several controls. These type definitions are deployed to MDS allowing us to share them across
Copyright © 2015 | All Rights Reserved SOA Magazine IV 24