Connector: Return attributes and keep payload unchanged.

I found the solution for my problem above, going down the road of processor and services. Everything is working as expected.

@estebanwasinger, Thanks a again for trying to help! However, this doesn't help me. My use case is, which works on 3.x:

1) On the start of the flow, drop a connector that will create a few properties/attributes to start the transaction, such as, start(date), transaction id(uuid), and few others. Input payload remain the same. And print out the the attributes including a log category to show the request started. e.g. "esb.work-order-adapter-v1.work-order-documents-update.start transactionID=cc43a212-afc6-11e8-a0c1-442420524153 creationTime=2018-09-04T08:15:00.019+10:00 txnState=start"

2)On the end of the flow, drop a connector that will update(if required) the properties/attributes created on start and add end(date) and print out the end of the transaction: e.g. "esb.work-order-adapter-v1.work-order-documents-update.end transactionID=cc43a212-afc6-11e8-a0c1-442420524153 creationTime=2018-09-04T08:15:00.019+10:00 txnState=end timeTaken=658"

We are able to do this on 3.x by just dropping a connector on the start and end of the flow and no payload is changed. We don't have to manipulate the payload in any mapping before doing this, etc. Also, we can use the category names to increase the debug level on these points if needed.

That's what I've been trying to achieve with 4.x connectors/attributes.

The 4.x logger component doesn't provide all that's required by us and it's not a connector but a processor, which isn't documented. If we try to implement our solution as a processor it may change again in future releases without notice.

@adilsoncom what you are missing is that in Mule 4 in any operation you can decide where to place the output, by default is the payload, but you can save the result of the operation in a variable, so you don't change the payload, for example, you have 2 JSONs with this structure:

 { 
   "message" : "a message"
 }

And you want to read those two files and compare if their messages are equals:

 <file:read path="/some/file1.json"/>
 <file:read path="/some/file2.json" target="file2" targetValue="#[payload]"/>

in this example, the behaviour is, that the file1 is placed on the payload and when you read the file2 you place the file content on the var file2, enabling you later, for example, use a DW Expression like #[payload.message != vars.file2.message].

targetValue can be any DW expression, but the most common values are: payload,attributes or message if you want to preserve the payload + attributes tuple.

Hope this helps you.

Hi Esteban, Thanks for your reply! However, what you suggest is not going to work for me as if I return the attributes as a payload, it will replace the existent payload, that's what I don't want to change. It does seem that Mulesoft has made things bit harder now. On 3.X we used the message properties for this and on 4.x we can't use the attributes. This will change a lot our implementation instead of just migrating from 3.x to 4.x. Anyway, I'll keep trying.

Hi Adilson,

That is the expected behaviour, by design, the attributes are metadata of the payload, so doesn't make sense to return just attributes and not a payload.

If your operation only returns attributes, would make more sense that those are your payload instead.