Description
Current behavior:
To pass data from trigger to flow activities, you have to declare them as trigger output, and flow developer have to either map all fields to the flow or map nothing. If map nothing, all data are automatically mapped and available to flow activities.
Expected behavior:
In my case, one of the request fields must be available to all activities in the flow, and so it must be automatically added to the flow input map, but other fields in the trigger output may be explicitly mapped by flow developers, and so the current implementation cannot guarantee that the required field is always available to all activities in the flow. I propose to update the Handler implementation to automatically add custom request context data to the flow input map, and so they can be used by all activities with or without explicit trigger output mapping.
What is the motivation / use case for changing the behavior?
In my use-case, the trigger is a singleton and so I do not need to handle multiple triggers. The flow will run on blockchain (Hyperledger Fabric in this case). The blockchain process starts a shim, that listens to blockchain requests, and passes request data to a Flogo flow. Although all request input data should be mapped by flow developer, there is an object, called "stub", which must be carried to all activities that update/read blockchain states. It would be error-prone to ask flow developer to explicitly map the "stub" in all activities. With this enhancement, we may make the trigger automatically store the "stub" in the flow, and so in the implementation of all blockchain activities, it can automatically fetch and use the "stub" when it is needed. Thus, flow developer would not even know that the "stub" existed under the cover.
Additional information you deem important (e.g. I need this tomorrow):