Trigger output attributes should be resolvable by activities

[yxuco]

I'm submitting a ... (check one with "x")

[] bug report => search github for a similar issue or PR before submitting
[X] enhancement request
[] feature request
[] support request
[] general question

Current behavior (how does the issue manifest):
Trigger output attributes by design must be mapped by an input mapper, and so the mapper result can be accessed by activities in the same flow. The required mapper configuration is inconvenient and sometimes error-prone.

Expected behavior:
By default, trigger output attributes should automatically assigned to a flow property of the same name, and so activities can access the trigger output attributes just like accessing other activity outputs. So, the trigger input mapper can be used to override the default behavior only when it is necessary.

Minimal steps to reproduce the problem (not required if feature enhancement):

What is the motivation / use case for changing the behavior?
In my trigger for hyperledger fabric chaincode, a stub object for each request received by the trigger must be accessible by subsequent activities. Since there is no way to pass the stub out and keep its scope for only a single request process, I wanted to store the stub as a trigger output. However, I do not want to rely on user to configure a correct input mapping for the stub, so I have to define the required mapping automatically. I worked around this issue by adding code (see below) to manipulate the app config with additional mapping for the stub before I use the config to create and start the flogo engine. This work-around is not ideal. A better solution is to change the behavior of flogo-lib/core.trigger.handler.go such that these input mapping for trigger output attributes are automatically done by default.

Please tell us about your environment (Operating system, docker version, browser & verison if webui, etc):

Flogo version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X

Additional information you deem important (e.g. issue happens only occasionally):
I am calling the following function to add input mapping for specified trigger types before I create and start a flogo engine. Such kludgy work-around would not be necessary if such mapping are automatically done in the trigger handler.

// inputAssignMap sets additional input mapping for a specified trigger ref type;
// this is to ensure the mapping of a trigger output property to avoid user error.
func inputAssignMap(ac *app.Config, triggerRef, name string) {
	// add the name to all flow resources
	prop := map[string]interface{}{"name": name, "type": "any"}
	for _, rc := range ac.Resources {
		var jsonobj map[string]interface{}
		if err := json.Unmarshal(rc.Data, &jsonobj); err != nil {
			logger.Errorf("failed to parse resource data %s: %+v", rc.ID, err)
			continue
		}
		if metadata, ok := jsonobj["metadata"]; ok {
			metaMap := metadata.(map[string]interface{})
			if input, ok := metaMap["input"]; ok {
				inputArray := input.([]interface{})
				done := false
				for _, ip := range inputArray {
					ipMap := ip.(map[string]interface{})
					if ipMap["name"].(string) == name {
						done = true
						continue
					}
				}
				if !done {
					logger.Debugf("add new property %s to resource input of %s", name, rc.ID)
					metaMap["input"] = append(inputArray, prop)
					if jsonbytes, err := json.Marshal(jsonobj); err == nil {
						logger.Debugf("resource data is updated for %s: %s", rc.ID, string(jsonbytes))
						rc.Data = jsonbytes
					} else {
						logger.Debugf("failed to serialize resource %s: %+v", rc.ID, err)
					}
				}
			}
		}
	}
	// add input mapper
	for _, tc := range ac.Triggers {
		if tc.Ref == triggerRef {
			for _, hc := range tc.Handlers {
				ivMap := hc.Action.Mappings.Input
				done := false
				for _, def := range ivMap {
					if def.MapTo == name {
						done = true
						continue
					}
				}
				if !done {
					logger.Infof("Add input mapper for %s to trigger %+v", name, tc.Id)
					mapDef := data.MappingDef{Type: data.MtAssign, Value: "$." + name, MapTo: name}
					hc.Action.Mappings.Input = append(ivMap, &mapDef)
				}
			}
		}
	}
}

[retgits]

I see your point, but it would make the use case where you have multiple triggers for a single flow pretty difficult. Especially if you have multiple triggers that don’t have the same output structure, the mapping is needed to make sure you can still do that.

Perhaps a good idea would be to have the mapping done automatically if you only have one trigger (which I thought was on the roadmap 🤔)

[yxuco]

Yes, I would discourage (actually disable) multiple triggers for a same flow. Instead, define subflows that can be reused by multiple flows, but limit one trigger per flow. That is how TIBCO BW has been worked for years.

[retgits]

Which is great for BW, but this isn’t BW 😉

[yxuco]

Of course it is up for debate regarding the pros-and-cons of different approaches (both achieve the same purpose.) For this issue, however, I hope that the API can expose a flag for automatically creating the input mapper if my trigger requires. Maybe when we send trigger-data to the handler, we can specify a flag to ask it to create input mappings automatically.

[yxuco]

Actually, all I need is to be able to specify which additional attributes need to be exposed as a flow property in the following call made by my trigger implementation: handler.Handle(context.Background(), triggerData). It would be easy to do, wouldn't it?

[mellistibco]

if you don't have any flow inputs defined, then the engine will pass the trigger properties to the flow and they will be referenced via $flow. @fm-tibco is that still the case?

flogo-lib/core/trigger/handler.go

Line 240 in efd198e

// for backwards compatibility make trigger outputs map directly to action inputs

[yxuco]

@mellistibco That might work if you do not define any input mapping, although in that case, you won't see any attributes on the Flogo UI, which would be a problem for UI modeling. Besides, why is the code that you mentioned adds 2 items to the inputs (one with the original attr name, another with a prefix "_T."?