Interesting, thanks.
Regarding adding additional information to the message, this is easily done. You can set any properties you like in the message context. These can be set from XPath expressions (at the port level), in a map (by adding a New Message Property in the tree), or in a Workflow (by using the syntax messageName[“propertyName”] = ... or messageName.MessageProperties[“propertyName”] = ... in VSTA – if using VB replace square brackets with round ones).
There is a predefined property called MessageID that you should in any event be able to use for your requirements. This is a GUID, and is guaranteed unique for any message in the system. It may change when a message is mapped, however, depending on the stage at which the map is applied (i.e. if the id has already been associated with the message in its previous form, it cannot also be applied to the mapped message).
If you want to trap errors, you will have to use a Map Activity in a Workflow, together with a FaultHandler activity for handling errors.
Regarding transactioning, at present there is a restriction whereby a Receive Activity cannot be in a TransactionScope. This is because Receive Activities handle their own transactioning, and the case is reasonably complicated as to rollback an activating receive would have to cancel the executing Workflow instance. Conceptually it is simpler to regard activating Receive Activities as atomic and irreversible. Full rollback behavior can still be achieved in a Workflow by sending the original message back to the original receive port (via a Send Activity).
There are also similar restrictions on Send and Receive Response Activities which have now been lifted in the latest version (1.3.16 - still in testing) – let me know if you want me to send you an update.
So your Receive Activity has to be at the start of the workflow outside of a transaction scope. But in the latest version you can then create a TransactionScope to deal with everything else, and you can update and query the database using Send and Receive Response activities inside this TransactionScope.
As an aside, we are working on a Database Activity for workflows, that will enable direct database interaction (querying and updates) without having to write any code or use Send and Receive Ports – is this likely to be of interest to you?
I’m aware that this may all sound a little confusing, but as always I’m happy to help you knock up a working prototype – let me know what I can do.
Thanks,
Ben.
Ben Jackson | SmartsIntegrator Support
Ben Jackson
SmartsIntegrator Technical Support