Bug 1314068 - BPM Suite 6.2 REST API for signalling exposes limited functionality
BPM Suite 6.2 REST API for signalling exposes limited functionality
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Maciej Swiderski
Lukáš Petrovický
Depends On:
  Show dependency treegraph
Reported: 2016-03-02 14:46 EST by Stephen Trombetti
Modified: 2016-03-23 09:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-23 09:56:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Trombetti 2016-03-02 14:46:42 EST
Description of problem:
I suppose this is more of a feature request than a bug report.

Signals within BPM contain a map of data inputs which can be of any Object type. These values are easy enough to assign and make use of when throwing a signal from within BPM. However, when a signal needs to be thrown from outside BPM via the REST interface this functionality is extremely limited.

The current REST call "/runtime/{deploymentID}/signal" supports query parameters "signal" and "event". This is sufficient for "signal" as it ends up mapping to SignalRef which is always a single String. "event" on the other hand is lacking as not only does it limit the potential number of data inputs to one but also imposes that that value is of type String, Integer, or Long.

It would be possible to serialize a data object as a String, pass it in via the "event" query parameter, then deserialize it. This is still limited in that there can only be one data input and that it imposes additional boilerplate work on the developer. Every time a signal of this type is caught manual deserialization will have to take place. Not only is this additional work but it creates a difference between a signal thrown from within BPM and one thrown from outside of it that will become costly both in processing power, developer time, and diagram readability.

For instance say you use the above approach and want to throw a signal from outside of BPM - the data is serialized sent via REST, caught by the signal receiver, then manually deserialized by a task after every receiver... This is starting to sound ugly. Now if you have more than one signal receiver the work will end up being duplicated for each one... This is starting to sound inefficient. Now say you want to throw this signal from within a BPM process, you'll have to serialize it with a task before throwing the signal, just so it can be deserialized when received... This sounds ugly and inefficient.

The inefficiency problem could be resolved by making use of a "deserialization" signal and process for each "internal" signal, both signals would have their own SignalRef. Calls to the REST API would always use the SignalRef of the "deserialization" signal, which would start a process that deserializes the event then throws the internal signal. BPM processes would just use the internal signal. The downside is that each internal signal then requires an additional signal and supporting process.

I'd like to propose that instead of using a query parameter to pass in the event, the POST data itself should be used - the JSON format would lend itself very well to this. The structure could work as follows:

{ "InputVar1": 1234,
  "InputVar2": "a string",
  "InputVar3": { "myNumber": 1234,
                 "myString": "another string",
                 "myObject": {"fib": 11235}}

Here the system could easily map multiple input variables to a signal, rather than the one currently supported, and it could support user defined data objects rather than just String, Integer, and Long. The type of the objects is known ahead of time so the mapping from JSON to Data Object would be simple. But wait there's more! This mapping would occur completely transparent to processes so there would be no ugly boilerplate. This also means that signals thrown through REST and from within BPM itself could be treated exactly the same, so no additional serialization and deserialization  or extra "external" signal&process would be required.

If you read through all of this thank you and please consider this request.

Version-Release number of selected component (if applicable):
BPM Suite 6.2

How reproducible:
Comment 2 Maciej Swiderski 2016-03-23 09:56:54 EDT
Thanks Stephen for detailed explanation and analysis. In BPMS 6.2 there is a new component called KIE Server aka execution server that provides REST api (and JMS too) which already has support for this. So I'd like to encourage you to give it a try as it does deal with complex types of signal events out of the box.

Moreover REST api in business central will most likely be replaced with KIE Server with next major version so there are no planned feature development activities in REST api of business central.

Note You need to log in before you can comment on or make changes to this bug.