FpML Issues Tracker
closed
Minor
Always
Business Process
Admin
mgratacos
Summary
It is impossible to unambiguously correlate from ContractFullTerminationCancelled to ContractFullTermination.
There is no unique identifier for a ContractFullTermination, so there is no way to always tie it back to a unique ContractFullTerminationCancelled.
There are various ways of matching based on TradeId, versionId, etc., but these don't guarantee unique correlation.
One possible solution is to add to ContractFullTermination an Id and then add a reference to that Id from ContractFullTerminationCancelled.
Notes:
matthewdr
04/07/08 5:32 pm
The same issue occurs with partialTermination, increase, and novation. The cancel events can’t tbe tied back to the thing they cancel.
iidal
05/09/08 9:11 pm
Hi Matthew,
Each cancel message has an optional event element which should contain an unambiguous reference to the message being cancelled.
ContractFullTerminationCancelled has FpML->termination->contractReference
ContractPartialTerminationCancelled has FpML->termination->contractReference
ContractNovatedCancelled has FpML->novation->{old|new}ContractReference
ContractIncreasedCancelled has FpML->increase->contractReference
Does that work?
Regards,
Lucio
matthew
05/10/08 8:50 am
Hi Lucio –
“ContractFullTerminationCancelled has FpML->termination->contractReference” – this is a reference to the Contract, not the ContractFullTermination.
For example, if a Contract had two ContractFullTerminations, you couldn’t tell the two ContractFullTerminations apart from each other.
The ContractFullTerminationCancelled needs to refer to the ContractFullTermination, otherwise you don’t know what it is cancelling.
mgratacos
05/12/08 4:07 pm
I think that in current implementations the correlation is done through the conversationId since there is no concept of object identifier within these messages.
matthewdr
05/12/08 4:17 pm
Lucio said: “Each cancel message has an optional event element which should contain an unambiguous reference to the message being cancelled.”
This works, but with the exceptions:
1. The MTF has a principle of referencing things in business terms, rather than message terms. This is due to the original event may not be advised in a message, even though the cancellation is.
2. Noy all my ContractFullTerminationCancelled flow by message. Sometimes other advice mechanisms are used.
matthewdr
05/12/08 4:18 pm
Marc – thanks for explaining how most people do this. Please can this method be documented in the FpML manual for business process until the definition is changed to correlate on a business identifier for the event being cancelled?
matthewdr
05/12/08 4:22 pm
The feedback from the development team on correlating by conversationId was that the scope of a conversation wasn’t defined, so different participants might scope a conversation to be single cancelFullTermination whereas others might scope it to be an entire contract. In summary, as conversation is undefined, it is difficult to use the concept.
mgratacos
04/23/10 10:46 am
This has been fixed in version 5.0:
3.2.3.5 Consistent Message Correlation
Principle: There should be a single, well-defined way to link successive messages (such as corrections or retractions of requests or notifications). This should not rely on message or transport level information, but rather use business-level information.
Implementation: Add an explicit correlation identifier, defined as business object identifier, and a sequence number to link successive messages.