This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Orchestration of Error Responses in a Batch"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) (New page) |
Rene spronk (talk | contribs) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{INM Finalized Workitem}} | ||
| + | |||
Issue: how does one deal with the grouping/routing of query responses if those contain errors? | Issue: how does one deal with the grouping/routing of query responses if those contain errors? | ||
| − | [[AORTA], the Dutch NHII, uses a central orcehstration manager application to route queries and responses. In a simplified scenario, | + | [[AORTA]], the Dutch NHII, uses a central orcehstration manager application to route queries and responses. In a simplified scenario, |
#The querying system queries the orchestration manager for the details of all medication supplies to patient #123. As far as the querying system is concerned the only party it is exchanging messages with is the destination of its query (the orchestration manager). It is the intent that the orchestration manager acts as a virtual frontend. | #The querying system queries the orchestration manager for the details of all medication supplies to patient #123. As far as the querying system is concerned the only party it is exchanging messages with is the destination of its query (the orchestration manager). It is the intent that the orchestration manager acts as a virtual frontend. | ||
#The orchestration manager doesn't have a copy of the clinical data, it only knows what other systems it should route this query to. Those systems that the query was sent to respond with 0 or more medication supplies to the orchestration manager. | #The orchestration manager doesn't have a copy of the clinical data, it only knows what other systems it should route this query to. Those systems that the query was sent to respond with 0 or more medication supplies to the orchestration manager. | ||
| Line 11: | Line 13: | ||
*System 3 responds with: AR(4) | *System 3 responds with: AR(4) | ||
*System 4 responds with: AA(5) | *System 4 responds with: AA(5) | ||
| + | |||
| + | ===When does a Query end?=== | ||
If we assume the above order is also the one used to route responses to the original querying system, then it receives | If we assume the above order is also the one used to route responses to the original querying system, then it receives | ||
*AA(1) AA(2) AE(3) | *AA(1) AA(2) AE(3) | ||
| − | At which point the querying system | + | At which point the querying system may stop listening for responses, because it has received an error. |
| + | Note: there may be business rules for certain queries to abort after having received the first AE, or an AE of a specific type. No such use-case is known at this point in time. | ||
| + | |||
| + | {{INM Motion|20070503 WGM Q3: An error (either AR or AE) reported the AcknowledgementTypeCode attribute in the transmission wrapper (in the query response interaction) when doing query continuations ends the query continuation, i.e. one may send no further query continuations. In the absence of an error the query ends when resultRemainingQuantity equals 0. (Doug/Sandy, 8-0-0}} | ||
| + | |||
| + | ===Orchestration Manager Scvenario=== | ||
| − | The orchestration manager could be | + | The '''orchestration manager''' |
| − | *AA(1) AA(2) AA(5) | + | #could be intelligent by grouping all errors/rejects into 1 final reponse interaction: |
| + | #*AA(1) AA(2) AA(5) AE(3,4) | ||
| + | #*This option requires that all detectedIssues and all syntax issues related to the query be grouped into this final Error interaction. | ||
| + | #Define that query results will be in random order and SHALL be processed until resultRemainingQuantity hits 0, regardless of AE/AR/AA. | ||
| − | + | Given the motion above option 1 should be used. | |
| − | |||
| − | |||
Latest revision as of 07:07, 9 May 2007
This page documents an INM Finalized Workitem, i.e. an issue within scope of the INM Committee that has been finalized, and which (if applicable) has been included in an INM ballot.
Issue: how does one deal with the grouping/routing of query responses if those contain errors?
AORTA, the Dutch NHII, uses a central orcehstration manager application to route queries and responses. In a simplified scenario,
- The querying system queries the orchestration manager for the details of all medication supplies to patient #123. As far as the querying system is concerned the only party it is exchanging messages with is the destination of its query (the orchestration manager). It is the intent that the orchestration manager acts as a virtual frontend.
- The orchestration manager doesn't have a copy of the clinical data, it only knows what other systems it should route this query to. Those systems that the query was sent to respond with 0 or more medication supplies to the orchestration manager.
- The orchestration manager changes the Transmission wrappers in the response interactions, and updates the information contained in the queryAck class so it will appear to the original querying system as if the response was generated by the orchestration manager.
This works just fine. Until we have a situation where 1 or more of the secondary systems being queried respond with errors/rejects (in any of its responses, it may sent multiple response messages to the query). Example:
- System 1 responds with: AA(1)
- System 2 responds with: AA(2) AE(3)
- System 3 responds with: AR(4)
- System 4 responds with: AA(5)
When does a Query end?
If we assume the above order is also the one used to route responses to the original querying system, then it receives
- AA(1) AA(2) AE(3)
At which point the querying system may stop listening for responses, because it has received an error. Note: there may be business rules for certain queries to abort after having received the first AE, or an AE of a specific type. No such use-case is known at this point in time.
Orchestration Manager Scvenario
The orchestration manager
- could be intelligent by grouping all errors/rejects into 1 final reponse interaction:
- AA(1) AA(2) AA(5) AE(3,4)
- This option requires that all detectedIssues and all syntax issues related to the query be grouped into this final Error interaction.
- Define that query results will be in random order and SHALL be processed until resultRemainingQuantity hits 0, regardless of AE/AR/AA.
Given the motion above option 1 should be used.
