The FpML Issues Tracker is designed to facilitate public interaction in the standard.
By registering to the Issue Tracker you will be able to submit corrections and comments, generate reports, and view the complete issues archive for FpML.
| Anonymous | Login | Signup for a new account | 2010-09-06 21:53 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0001000 | [FpML] Feedback and Suggestions | feature | always | 2010-01-14 16:39 | 2010-02-01 09:16 | ||||
| Reporter | SBoroditsky | View Status | public | ||||||
| Assigned To | mgratacos | ||||||||
| Priority | normal | Resolution | no change required | ||||||
| Status | closed | Target Version | Product Version | 4.6 Recommendation 2009-09-10 (build 7) | |||||
| Summary | 0001000: Batch transfer of trades produces a partyid conflict | ||||||||
| Description |
We are working on a FTP drop of FpML formatted contract messages and have an issue with more than one FpML document in a single file due to multiple declarations of the same party (i.e. the partyid="party1" appears more than once in the file). Is there a recommended way to handle batch transfer of contract documents or is this type of optimization not supported (i.e. each message must be sent and processed individually rather than in a batch)? |
||||||||
| Additional Information | |||||||||
| Tags | No tags attached. | ||||||||
| XML Tool Type | |||||||||
| Attached Files |
 SampleBatchFeed.xml [^] (13,423 bytes) 2010-01-14 16:39 batch.party.id.xsl [^] (1,338 bytes) 2010-01-28 12:54 |
||||||||
|
|
|||||||||
 Relationships |
|
|
Notes |
|
|
(0002548) mgratacos (administrator) 2010-01-27 15:41 |
I've seen different ways to handle this. Some people append an additional identifier to the id attribute value to make it unique through the batch file. For example, to append the trade id value. In the first trade of your example, <party id="1234party1">, 1234 being the tradeId value, which should be unique across multiple trades. Some people use the same value as the partyId element value (1234) and the code is smart enough to remove duplicate parties. |
|
(0002549) BrianLynn (developer) 2010-01-27 18:58 |
Best practice is to track the parties that are needed in the file and ensure that each party is generated only once. The party id attributes need to be unique; this can be done using a firm-specific identifier or by generating a unique ID value (could just be a sequential number). All parties appear in the file after all position or trade records, so by the time you are writing out the parties, you know which ones you need. A number of firms have implemented this so this approach is known to be implementable. |
|
(0002550) h_mcallister (developer) 2010-01-28 13:03 edited on: 2010-01-28 15:33 |
Here is a simple stylesheet which implements Marc's suggestion of appending a unique suffix to the @id (please see batch.party.id.xsl, attached) - I use the ordinal position of the FpML document in the batch file to guarantee uniqueness (tradeId is okay only if you are certain that it cannot be repeated within the batch document). The stylesheet is based on the identity transformation; the identity behaviour is modified for instances of partyReference/@href and party/@id, which are suffixed to guarantee uniqueness. Note that the new id/href value is based only on the properties of the referenced/identified party, not on the original id/href values - so you could create an entirely new id/href scheme if desired, while maintaining the original referential integrities. Marc & Brian both mentioned the possibility of eliminating duplicate parties, which is a reasonable aim. The FpML DataDocument allows multiple trades to be included in a single message, followed by a collection of (preferrably unique) parties - however FpML does not provide a structure to support mixed processing semantics on multiple trades (e.g. TradeExecution, TradeExecutionModified, TradeExecutionCancelled). Best regards, Harry McAllister |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2010-01-14 16:39 | SBoroditsky | New Issue | |
| 2010-01-14 16:39 | SBoroditsky | Status | new => assigned |
| 2010-01-14 16:39 | SBoroditsky | Assigned To | => mgratacos |
| 2010-01-14 16:39 | SBoroditsky | File Added: SampleBatchFeed.xml | |
| 2010-01-27 15:41 | mgratacos | Note Added: 0002548 | |
| 2010-01-27 18:58 | BrianLynn | Note Added: 0002549 | |
| 2010-01-28 12:54 | h_mcallister | File Added: batch.party.id.xsl | |
| 2010-01-28 13:03 | h_mcallister | Note Added: 0002550 | |
| 2010-01-28 15:33 | h_mcallister | Note Edited: 0002550 | |
| 2010-02-01 09:16 | mgratacos | Status | assigned => closed |
| 2010-02-01 09:16 | mgratacos | Resolution | open => no change required |
| 2010-03-03 10:32 | BUTTER | Issue Monitored: BUTTER | |