Bug 1314068

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:
always