Generic Async Service Catalogue - Vlaanderen



CIN/NICiSocialGeneric AsyncService CatalogueIndex & description of the Async Services offered by iSocial platform.Atos TIME \@ "d/MM/yyyy" 11/12/2017Description of the different business interfaces that iSocial broker provides via the SSO/ESB or SSO-Only service. These are web services that can be used by the care providers to communicate with the different health insurance organizations. Only the business part, or the SOAP-bodies, are described in this document.Contents TOC \o "1-3" \h \z \u 1Revision table PAGEREF _Toc500531565 \h 32Introduction PAGEREF _Toc500531566 \h 52.1Audience PAGEREF _Toc500531567 \h 52.2Goal of the document PAGEREF _Toc500531568 \h 52.3Document License PAGEREF _Toc500531569 \h 53Generic Async. flows PAGEREF _Toc500531570 \h 63.1Basic Principal PAGEREF _Toc500531571 \h 63.2Generic Async Interface PAGEREF _Toc500531572 \h 63.2.1RequestFlow overview PAGEREF _Toc500531573 \h 63.2.2Service operations PAGEREF _Toc500531574 \h 103.2.3Hash or Reference PAGEREF _Toc500531575 \h 113.2.4Ws-addressing PAGEREF _Toc500531576 \h 113.2.5post-operation PAGEREF _Toc500531577 \h 113.2.6get operation PAGEREF _Toc500531578 \h 143.2.7confirm operation PAGEREF _Toc500531579 \h 183.2.8Versions PAGEREF _Toc500531580 \h 193.3Carenet Header PAGEREF _Toc500531581 \h 213.4Extension PAGEREF _Toc500531582 \h 213.4.1Encrypted content (New from version 1.3) PAGEREF _Toc500531583 \h 213.4.2Probative force PAGEREF _Toc500531584 \h 223.4.3Business Negative acknowledgement PAGEREF _Toc500531585 \h 22Revision tableRelease No.DateRevision Description1.0Initial revision (from NIPPIN service catalog)IntroductionAudienceThis document is intended for analysts, architect and developers of all client applications. It includes both Package Providers and Relaying Parties. See lexicon for definition of package providers and relaying parties.Analysts can use the service index section of this document to see which services are available. Architects are most likely interested in the entire document, except for the exact message structure parts of the service index. The developers should be aware of the entire content.Goal of the documentThis document intends to describe the different async. services of iSocial message broker implemented using the Generic Async Interface and available for external clients, independent of the communication (SSO/ESB or SSO-Only). It is more than just an index; it also provides information about the design of the service. This allows architects of client applications to align their own architecture.This document is limited to the new business oriented services; it does not cover the general-purpose interface that accepts a Care Provider Document. For this the existing Care Provider Implementation Guide remains the reference.Document License[[TODO]]Generic Async. flowsBasic PrincipalThe Generic Async. WebService follows the base principle, service versioning and lifecycle, message traceability, interoperability and best practices of iSocial standards (see Service_Catalogue_iSocial_Commons.docx). Generic Async InterfaceThe Generic Async. interface allows the care provider to send requests and receive responses to/from partner organisations in an asynchronous communication scheme: the iSocial broker takes the message delivery in charge.Note: flows (‘responses’) can be initiated by the partner institutions (without the need for a request from the care provider).RequestFlow overviewThe following uses cases are involved in sending and receiving async. messages from/to iSocial broker.Pre-requisiteSending and receiving messages are protected by the SSO mechanism of eHealth. This requires a SAML ticket that can be used for all added value services like MyCareNet. The detailed information about the SSO can be found with eHealth, but here is a short overview.The Care Provider sends a request for a ticket to the STS of eHealth, see authentication catalogue for the required attributes.eHealth will verify the provided attributes and issue the requested attributes when the verification is successful.eHealth returns a SAML-ticket that must be used by the Care Provider in the next sections.Send Async MessageThe present scenario doesn’t describe how the business message is prepared, only how it is sent to the broker and delivered to the partner institution. When relevant (i.e. the flow requires probative force on request), the sender creates a XAdES-BES as defined in Service_Catalogue_iSocial_Commons.docx. The signing certificate must be the eID signature or the eHealth authentication certificate of the care provider.In case a Xades-T is required, requests a timestamp of the signature value to the timestamp authority of eHealth. It is important to send the hash and not the signature value itself since eHealth will not calculate the (hash) value correctly.Note: Depending of the version of the timestamping service, eHealth will return (3) the timestamp (incorrectly) double base64 encoded.The eHealth timestamp must be added to the XAdES-BES to make it a XAdES-T. For more information about this, and the previous 2 steps, see Service_Catalogue_iSocial_Commons.docx.4. The care provider must create a common input according to the requirements and a detail based on the s specs of the flow. It must send these (with, when relevant, the XAdES) to the broker using the post-method. For this it needs the ticket from the pre-requisites.4.1. the broker will verify that the input is technically correct (when relevant, there is XAdES, it has the required fields, …).The broker will keep the input to send to the partner on a later moment.It will return an unsigned tACK indicating the message was received by the broker, see below for the format of the tACK. broker can also send a NACK, indicating the message was not sent to the destination.4.4. the broker will route the input to the required destination. This can either - be based on the “To” field of the WS-Addressing standard (called direct routing)- be based on the common input content (called dynamic routing, future)- be sent to all registered partners (called broadcasting)4.5. The broker will send the request to the destination so it can be processed.5: The recipient will do a full technical validation of the request. It will check the Xades (if required) and create a tACK with the right status and value.6: The recipient will keep the request for processing. This processing is done asynchronously on a later time.7-9: The recipient will create a XAdES-T (with timestamp-retrieval) on the tACK. See 1-3.10. The recipient will return and tACK with, if applicable, Xades-BES or XAdES-T that is intended for the care provider. This will be returned to the care provider during the receive phase.Receive Async MessageThe care provider has the possibility to retrieve the responses of the partner institutions. This includes both the technical ACKs/NACKs (=acceptance/refusals) and the business messages.The partner institution creates a response, this can be because of request or on the initiative of the partner itself.If needed by the flow, the partner creates a xades-t for the response.The partner institution places a response on the broker for a specific end user. When relevant (i.e. the flow requires probative force on the response), the response id provided with a XAdES-T proof. This XAdES-T is signed with the certificate of the partner institution. It is kept next to the signed tACKs that were received from the partner (see the send Async message point 8).The broker confirms the reception to the partner, but this is transparent for the end user.The end user, recipient of the message, must request the files available for him by executing the get-method. It must provide information about him and which responses it wants. More on that later. It also needs the ticket of the pre-requisites for this.The broker will retrieve all the signed tACKs that where requested by the end user.The broker will retrieve all the signed responses that where requested by the end user.The broker will return both the signed tACKs and the signed responses to the end user. It will use MTOM/XOP for performance reasons.For the flows supporting it, the end user may extract and validate the hash values of the signed responses (provided in the output) and content of the tACKs.The care provider must confirm the reception of the tACKs and responses to not receive them anymore. For this it needs to specify who he is (with the ticket of the pre-requisites) and which messages he wants to confirm. MTOM/XOP is used, not for performance, but for compatibility reasons with the get and post method.The broker will remove the signed tACKs so they are no longer part of the returned valuesThe broker will remove the signed responses so they are no longer part of the returned valuesThe broker will indicate to the user the confirmation was processed correctly by returning an empty response.8-10/ When provided, the receiver should verify the probative force on the response:8. verify the xades-t of both the tACKs and the responses it got from the partner. See Service_Catalogue_iSocial_Commons.docx for more information.9. Because we use XAdES-T and not XAdES-X-L, the care provider will have to verify the status of the certificates (signer + timestamp authority) with the help of the Fedict OCSP or CRLs.10. The response of the Fedict OCSP or CRLs will be status ok or not for the certificates. Probative forceIf we assume there was a single business request with a single business response, the following messages are available after sending and receiving:During the post, the business request is embedded in a blob as base64 after it has been encrypted or deflated. The XADES provided by the end user must reference the blob and have transforms to first base64-decode and then inflate. In case the Xades has a timestamp, this provides probative force of the business request. This is the case for all current business cases.The result of the post is a tACK (see below for details). There is no Xades for this tACK, and therefore it has not probative force.During a get, the method returns tACK’s that come from the sender. These have the same structure as the tACK from the broker but can have a different status. In this case there may be a Xades-T that provides probative force for the tACK. This Xades has a reference to the tACK and has a base64-decode transform (but not inflate transform) so only the HMAC value is signed. As indicated before, the HMAC is based on the business request and the status, so the tACK with Xades is proof a business request was accepted/rejected by the partner.The Xades of the tACK might contain a manifest that has a reference to the blob of the business request.The get method also returns business responses, embedded in a blob as base64. Non-encrypted content is being deflated first. The Xades-T provided by the partner references the blob and has transform to first base64 decode and then inflate it. This provides probative force on the business response.Service operationsThe service offers 3 operations: post, get and confirm:Hash or ReferenceDepending on the cases, the Tack (return from post or delivery confirmation from the partner) may contain a HMAC value of the request (base64 decoded) or a simple reference.HMAC is used up to version 1.1 of the service. HMAC is manually calculated on the clear version of the business request, where the key/salt is the status of the tACK. Since the references are manual, there are no transforms defined. The package must do the base64-decode and inflation itself if the source is in clear format.Reference is used from version 1.2 of the service.Ws-addressingWs-Addressing is required for all calls to the genericAsync service (any operations). The W3C specification describes the mandatory and optional WS-addressing headers :The values allowed for the “To” header are defined per operation. The values for the “Action” header are specified in the wsdl of the service./wsa:To This REQUIRED element (of type xs:anyURI) provides the value for the [destination] property./wsa:Action This REQUIRED element of type xs:anyURI conveys the [action] property. The [children] of this element convey the value of this property./wsa:MessageID This OPTIONAL element (of type xs:anyURI) conveys the [message id] property. This element MUST be present if wsa:ReplyTo or wsa:FaultTo is present./wsa:RelatesTo This OPTIONAL (repeating) element information item contributes one abstract [relationship] property value, in the form of a (URI, QName) pair. The [children] property of this element (which is of type xs:anyURI) conveys the [message id] of the related message. This element MUST be present if the message is a reply./wsa:RelatesTo/@RelationshipType This OPTIONAL attribute (of type xs:QName) conveys the relationship type as a QName. When absent, the implied value of this attribute is wsa:Reply./wsa:ReplyTo This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. This element MUST be present if a reply is expected. If this element is present, wsa:MessageID MUST be present./wsa:From This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [source endpoint] property./wsa:FaultTo This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [fault endpoint] property. If this element is present, wsa:MessageID MUST be present.post-operationThe post operation is used by end users to send a (business) message to the broker to be delivered to the partner institution.Message descriptionInputThe post element is made of 3 elements:CommonInput : iSocial standard (see Service_Catalogue_iSocial_Commons.docx)Detail: the business data routed to the destination (see Service_Catalogue_iSocial_Commons.docx). The content of the blob is specific for each flow implemented via Generic Async. interface (see business flow description here under for more information).Xades-t: when required (depends on each flow), the (request) probative force data see (see Service_Catalogue_iSocial_Commons.docx)Base64 parts (Detail and Xades-t) must be transported as MTOM/XOP. This will split the xml from the binary data. The xml will contain a link to the data that is transferred as additional parts of the multipart http request.There are 3 options to resolve the routing of the message. Each business flow will be configured to use one (and only one) of them:direct routing: business flows can be configured to use the “To” header of the WS-Addressing. The format, when addressing must be as follow:Type of recipientpatternInsurance organismurn:nip:destination:io:<IO id> where <IO Id> is the identifier of the IO in 3 digits (100, 200, … 900)Payment organismurn:nip:destination:op:OP<POid> where <POId> is the identifier of the Payment Organism in 1 digit (1, 2, 3, 4)Other organizationurn:nip:destination:cbe:<CBE> where <CBE> is the entreprise number of the partner institutiondynamic routing (future): the routing is based on information provided in the Routing-element on request (not yet present).Broadcasting (default): messages can be sent to all registered partners. This is the default mode when the “to” header is present and not filled (empty or blanco string as value) or filled with the value urn:nip:destination:io:MULTICASTDepending on the flow a specific routing mechanism may be enforced or a routing mechanism may be restricted.OutputThe output of the response is a tACK, which gives some an informal proof to the care provider that the message was accepted by the broker. It is the same type of tACK that is returned by the partner institution itself (later in the process), but it isn’t signed. The tACK returned here is issued by the broker and has not legal value. The next section describes a tACK with the same structure that is signed and is issued by the recipient. The second tACK (issued by the IO) is legal proof that the message was received by the Irecipient The result major indicates if the message was accepted by the broker. If different from success, the result minor and message define why it was refused. The message should be corrected and resent afterward.The tACK has the following structure:(Content): HMAC-SHA256 of the blob content (decode and inflated) of the received detail where the Result Major is used as key.@Issuer: indicates the issuer of the tACK.@Applies To: indicates the common input/output reference for which it applies. In this case it is always “urn:nip:reference:input:xxxxxx”, where “xxxxx” is the actual reference of the post.@Result Major: indicates if the is an ACK or a NON-ACK. The values are:ACK: urn:nip:tack:result:major:successNON-ACK: urn:nip:tack:result:major:failure@Result Minor: reason of the failure or warning message with success. This list isn’t fixed, but dynamic in time. An up to date list will be available when the services are available.@Result Message: A human readable description of the result, in English.@Id: not used here since this tACK isn’t signed.@Reference (new from version 1.2) : As for Blob, depending on business, this may replace the Hash (Content) and used as simpler correlation identifier. Choice between Reference or Hash is defined per message. FaultIn case of a technical error, a SOAP fault as defined in the common section is returned.get operationThe get operation is used by end users to:retrieve business messages posted by the partner institution and addressed to them retrieve (legal) tAck given by the partners when they received the async. requests issued by them.It isn’t allowed or possible to execute multiple requests to the same service at the same time (end users must poll on messages and tACK using this operation with a ‘reasonable’ frequency).Message descriptionInputThe get input does not contain a common input because the common input contains fields that are only applicable on a (business) message. Since the get doesn’t contain a message, it doesn’t require a common input. It does have an origin, because the care provider must indicate who he is. The origin is used as part of the query. The requirements of the origin are the same as the origin of the common input described in Service_Catalogue_iSocial_Commons.docx.(New from version 1.2) With the QueryParameters, the caller may decide to filter the results coming from specific partners only or to get the result corresponding to a single reference.With the message query (MsgQuery element), the care provider can specify which responses of the IO it wants to receive. The format is as follows:@Include: set to false if no responses should be returned, the default value is “true”Max: The maximum number of responses that should be returned by this call. The default is (version <= 1.2) “100”(version >= 1.3) “1” when encrypted content is possible, “100” otherwise.Use “1” to download the messages sequentially.Message Names: A list of message names that should be returned. The list is a standard xml list, which means the elements are separated by spaces. The requested names must match exactly the “message name” attribute of the required detail blobs. Wildcards or any other expressions aren’t possible, but an empty list means “ALL”. The service will only return the messages that are linked to this URL. Specifying messages names that are served by a different service (URL) with the same interface will not return any result. See service index to see which messages are behind which URL.The tACK query (TAckQuery element) allows the care provider to specify which tACK of the partner should be returned. These tACK are generated by the partner when it receive a request (inbound message) from the care provider that was sent by the post-method.The fields are exactly the same as for the messages, except for the absence of a MessageNames element. This means that you can control the number of returned tAcks, but they are always for “ALL” (inbound) message names.Even if the Ws-addressing “To” header is required, its value may be left empty.(New from version 1.3) When the user expects encrypted content to be returned, he may specify (strongly encouraged) the Etk to be used for the encryption of the response. This Etk should be provided in Base-64 in the “<Reply-to-Etk>” element of the get request. OutputAs with the request of the post-method, the response of the get-method requires MTOM/XOP. This will split the binary data from the XML and send them as an HTTP multi-part.The format of the output is:It contains a return-element to be compliant with both Java and .Net wrapping-rules, which contains the responses in the following structure.@Message Count: Number of IO responses that are included. Always less or equal to the max provided in the relevant query. This is purely informational and allows pre-allocation of resources when needed.@tACK Count: Number of tACK the partners provided. Always less or equal to the max provided in the relevant query.Message Response: list of business responses provided by the partnersCommon Output: the common output as defined before. Because there is no correlation with the request, only the output and NIPreference will be provided.Detail: blob as defined before with as content the deflated and encoded business message. (version 1.1 only) detail tag defines the HashValue to be used in the confirm method(new from version 1.2) Depending on business context, detail tag may define HashValue and/or reference, to be used in the confirm method(new from version 1.3) In case of encrypted content, the attribute @ContentEncryption indicates that content has been encrypted for recipient, and the attribute @Etk may be present to indicate the token used fort he encryption of the message. In this case, the value of @ContentEncoding should be “none”. See Service catalog commons for more details about thisXAdES-T: The XAdES-T as defined above which provided probative force of the detail content.tACK Response: list of tACK provided by the partnerstACK: The technical ACK of the request send by the care provider. See below for more information.XAdES-T: The XAdES-T as defined above which provided probative force of the tACK content.The tACK returned in the get response has the same structure as the tACK of the post, but the content (meaning) is different: it is the legal proof that the message was received by the recipient. This is the only tACK that is required, but it can take a while (up to 24h and more) before it is provided. Because of this potential delay, the broker delivers an “intermediate” tACK that can be used as proof of delivery, but without the legal value.The structure is:(Content) (up to version 1.1): HMAC-SHA256 of the blob content (decode and inflated) of the received detail where the Result Major is used as key.@Issuer: indicates the issuer of the tACK. For insurance organisms, it is always “urn:nip:issuer:io:xxx”, where “xxx” is 100, 200, 300, 400, 500, 600 or 900 depending on the IO. For other partners, it is “urn:nip:issuer:io:cbe:<CBE>”@Applies To: indicates the common input/output reference for which it applies. In this case it is always “urn:nip:reference:input:xxxxxx”, where “xxxxx” is the actual reference of the post.@Result Major: indicates if the is an ACK or a NON-ACK. The values are:ACK: urn:nip:tack:result:major:successNON-ACK: urn:nip:tack:result:major:failure@Result Minor: reason of the failure or warning message with success. This list isn’t fixed, but dynamic in time. An up to date list will be available when the services are available.@Result Message: A human readable description of the result, in English.@Id: A fixed (e.g. tACK) or dynamic (e.g. urn:uuid:xxxx) id of the tACK that is used in the XAdES-T signature.@Reference (new from version 1.2): As for Blob, depending on business, this may replace the Hash (Content) and used as simpler correlation identifier. Choice between Reference or Hash is defined per message.FaultIn case of a technical error, a common fault is returned.Repetitive call limitationLimitation mechanism protects the iSocial brokerfrom useless repetitive calls. Indeed, 2 successive calls to the get operation in a short timeframe may return the same result. In order to limit the impact on the platform, the repetition of “get” calls, without calling a “confirm” in between, will be prohibited by the platform. The admissible delay between 2 successive calls will be configured per flowDelays are checked and calculated independently for TACK and for OUTBOUND messages.For each service.Encryption and timeoutIn case of encrypted content, the client application should allow a sufficient time for the timeout of the get operation. Indeed, depending of the size of the messages, the encryption operations may induce significant delays in the delivering of the response of the get.confirm operationThe confirm operation is used by end users to confirm the reception of a message (via get operation) and therefore remove it from the broker. Until they are confirmed via this operation, messages will be returned by the get operation (and, in other words, potentially sent several times).Message descriptionInputBecause MTOM/XOP is activated on the entire service, it will be used for this operation too but isn’t required. The xml-payload looks the following:The origin is to make sure that a care provider can only confirm its own documents. As with the get-operation, this is in place of the common input since that is only for messages.(Up to version 1.1) The MsgHashValues is a list of base64 encoded SHA-256 hash values of the received responses. This must be calculated on the decompressed and decoded content of the detail blob. The care provider system must not calculate this himself, it is pre-calculated and provided as attribute of the blob (in the get response).Notice that it is a list, so there can be multiple values: one for each received message. The different values must be separated by a space.The tACK contents element is similar to the message hash values. It confirms the reception of the tACKs and makes sure they are removed from the broker. It is also a list of base64 encoded value, but this time it is the content of the received tACK. There isn’t the need to hash it because it is already a hash.(New from version 1.2) The MsgRefValues collection contains a list of Reference of msgResponses.The TackReferences collection contains a list of Reference of msgResponses. Even if the Ws-addressing “To” header is required, its value may be left empty.OutputThe output is empty, which indicates that the “confirm” was processed correctly. In case there is an error, a fault is returned instead of the empty response.FaultIn case of a technical error, a common fault is returned.VersionsVersion 1.0Status: Removed (compatible with 1.1)Initial version.Version 1.1Status: MaintainedChanges:Added multicast routing.Selection of inbound message name to query tACKMade Xades-T optionalNo migration needed.XSD referenceDocumentVersionCommonInfo-basisV2CommonInfo-refV2CommonInfoV2CommonTypesV1Version 1.2Status: maintainedChanges:Additional parameter for get queries to filter originating IO (inclusion or exclusion).Additional parameter for get queries to point a specific referenceAdditional information in post result : Reference in TackAdditional information in get result : Reference in TackReference and issuer in MsgResponseAdditional parameters for confirm request to give references (instead of hashes).XSD referenceDocumentVersionCommonInfo-basisV2CommonInfo-refV2CommonInfoV2CommonTypesV1.3Version 1.3Status: maintainedChanges:Support for encrypted contentXSD referenceDocumentVersionCommonInfo-basisV2CommonInfo-refV2CommonInfoV2CommonTypesV1.4ExtensionEncrypted content (New from version 1.3)In case of encrypted content, the content of the tag detail will be the base-64 representation of the encrypted content. The value of the attribute ContentEncryption indicates if the content has been encrypted. The details of the possible values is defined in the Service_Catalog_Commons.The content of the encrypted message should respect some standard format to support probative force of the message.Message formatThe content of the blob transmitted between end users and partners organisms will respect the following structure:This message is composed ofReply-to-Etk : Not to be used for Async flows. This zone indicates the etk to be used for the encryption of a synchronous response.BusinessContent: the business message (KMHER). This tag has the following attributes:id: identify the tag for reference in Xades signature. The value is a unique identifier respecting the standard ID XML format.ContentType: indicates the type of content. Default (when not specified) is “application/octet-stream”ContentEncoding: indicates if the content has been deflated or not. Default is “deflated”.Xades: the XAdES signature referencing the BusinessContent (via its standard “id” attribute)Encryption tokens (Etk)(version >= 1.3)Selection of the ETK used for encryption is done using the following rules :1/ The end user may specify the ETK to be used in the Get parameters. This is the recommended way of working2/ When no etk is given in the get parameters, the etk is selected from etkDepotWith an applicationId specific to the iSocial platform deployment.If none of the etk matches the applicationId, the first etk availableTo support mandate usage, the etk selected in the etkDepot corresponds to the effective sender of the get request.In any case, the etk effectively used for encryption is specified in the @Etk attribute of the MsgResponse. Probative forceThe probative force is a Xades-BES or a XAdES-T signature, as defined in the service_catalog_commons.In case of encrypted content, the XadES signature is put in the encrypted body in the tag EncryptedKnownContent/Xades and the signature references the content of the EncryptedKnownContent/BusinessContent via its “xml:Id”. In this case, the custom transformation rule “urn:nippin:xml:sig:transform:optional-deflate” may not be appliedIn case of non-encrypted content, the XadES signature is put in the Xades-t tag of the request or the response and the signature references the content of the detail via its Id. In this case, the custom transformation rule “urn:nippin:xml:sig:transform:optional-deflate” may be applied if needed.Business Negative acknowledgementA specific standardized message is defined to enable rejection of received messages. With this message, it is possible to refuse an already received async message and the partner can be informed via the generic async message.This kind of message will have the message name ‘REJECT’ in the ‘Detail’ tag of the generic async request and For package providers, be made available on the same endpoint as the sent message. This one is coming with the business responses in the get operation result.For partners organisms, be transmitted to their integration module.The content encoding attribute of the Detail tag is ‘none’. So it is not compressed!This functionality is not systematically supported for all business. When supported it is clearly mentioned in the corresponding documentation.Rejection by the PartnersThe recipient can reject the incoming message by generating an outbound message that contains in the detail value an xml with root tag ‘RejectInb’. This message will be received by the care provider and proper actions/corrections should be performed and the corrected message should be resent.The structure is:msgName: original message moninput: refers to the commoninput of the rejected message that will be refused. This tag should be a copy of the commoninput of the rejected message. (structure description see Service_Catalogue_iSocial_Commons.docx)Fault: the fault description (structure description see Service_Catalogue_iSocial_Commons.docx).Rejection by the end userThe end user can reject the incoming message by generating a message that contains in the detail value an xml with root tag ‘RejectOutb’. This message will be received by the partner and proper actions/corrections should be performed and the corrected message should be resent.The structure is:msgName: messageName of the rejected messageCommonouput: refers to the commoninput of the rejected message that will be refused. This tag should be a copy of the commonoutput of the rejected message. (structure description see Service_Catalogue_iSocial_Commons.docx)Origin: refers to the Origin of the rejected message that will be refused. This tag should be a copy of the Origin of the rejected message. (structure description see Service_Catalogue_iSocial_Commons.docx)Fault: the fault description (structure description see Service_Catalogue_iSocial_Commons.docx). ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download