|
|
| Line 1: |
Line 1: |
| − | {{INM Workitem}}
| |
| − | Back to [[Infrastructure and Messaging TC]]
| |
| | | | |
| − | == Known Issues ==
| |
| − |
| |
| − |
| |
| − |
| |
| − | === MCCI Batch ===
| |
| − |
| |
| − | '''Batch class'''
| |
| − | *(medium) Consider 1 Batch resulting in exactly 1 batch with application responses. See [[Batch Transmission Pattern]] for details, we may want to introduce 2 new attributes.
| |
| − | *(MEDIUM) The Response Mode as contained in the batch overrules the Response Mode as defined by individual interactions contained in the batch. Do we really want to do this? I can understand sometimes wanting to override it ... but I can also see cases where one would want the Response Mode of the individual interactions to be honored. Maybe the vocab domain could be extended to include an 'honor individual interaction response modes' term?
| |
| − | **delete responseModeCode from batch
| |
| − | *(medium) Batch acknowledgement mechanism, open MCCI line-items 68, 69. Batch responseMode attribute, open MCCI line-item 146.
| |
| − | *(minor) Mead Walker/Robert Hausam have come forward with use-cases for the inclusion of a time-interval of a Batch (e.g. this is a batch containing all invoices from 20050101 up to 20050201) - The comittee has commited itself to include a solution for this use case in the next publication of the MCCI domain.
| |
| − | *(closed, CfH, Sept2006) Requirement for long term planning: InM to provide a solution to batch messaging that does not require message headers to be unnecessarily repeated (taking up a lot of message space and network bandwidth) and at the same time provides the mechanism to respond to individual [[Detected Issue|detected issues]].
| |
| − | **20070109 WGM. Closed, covered by new [[Behavioral Contract Wrapper (new wrapper mechanism)|Behavioral Contract Wrapper]].
| |
| − | *(closed) Mead Walker/Robert Hausam have come forward with a use-case for the inclusion of a BatchTypeCode. Batch.name is of datatype SC, so a code can be supplied. Only open issue is if we should rename the attribute, which has RIM backwards compatibility issues associated with it. MCCI line-item 171
| |
| − | **20070109 WGM. Batch has been redefined to be a grouper for transmission purposes only. **Either payloads of the same type can be sent in one Message interaction. Payloads of different types can be grouped under the new [[Behavioral Contract Wrapper (new wrapper mechanism)|Behavioral Contract Class]].
| |
| − |
| |
| − | *(issue resolved, needs to be documented in next release) It is the intent of the committee not to require an instance of the reference control id attribute in the initial batch transmission. (John Arnett / Tony Davey 11–0-3 Jan06 WGM THU Q4)
| |
| − | *(issue resolved, needs documentation) There is an element of tension between the statement that a Batch wrapper is "only a grouping of interactions for transmission purposes" and the presence of the batch.referenceControlId and batch.name. These seem to hint that a Batch is a "unit of processing". Well: is it, or isn't it?
| |
| − | **INM out of cycle: Transmission Wrapper will be a thin grouper of transmissions only. NHS use-case for syncing databases via message-batches will be discussed separately.
| |
