You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
The text was updated successfully, but these errors were encountered:
yxuco
added a commit
to yxuco/core
that referenced
this issue
Dec 10, 2020
…move 'vendor' path
allows trigger developer to pass request parameters to handler w/o going through output mapper
Resulve issue project-flogo#224 GetRef() in support package should remove 'vendor' path
resubmit pull request to resolve issue project-flogo#224Fixproject-flogo#244 Trigger handler should provide option to pass request data to flow without explicit output mapping
update per comments on issue project-flogo#246
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):
The text was updated successfully, but these errors were encountered: