Because of vagaries in the RNIF standard, Activator has devised a way to pass the GlobalUsageCode and PipInstanceId to and from back-end applications. There are two use cases: with MMDs and without MMDs. You need these so that your back-end system can deal with either case.
For inbound integration, if MMDs are used Activator produces an MMD to integration containing values for the GlobalUsageCode and PipInstanceId (see the folllowing figure). For outbound integration the GlobalUsageCode and PipInstanceId can be included in the MMD. For response messages of dual-action PIPs, the PipInstanceId and InReplyToTrackingId also must be included in the MMD. If included within the MMD, the GlobalUsageCode, PipInstanceId and InReplyToMessageId values from the MMD are used in the packaged RNIF message.
The following example illustrates an MMD produced for inbound integration.
|
|
If MMDs are not used, the outbound service content can be parsed to determine the PipInstanceId, GlobalUsageCode, InReplyToTrackingId and InitiatingRoutingId to use in the packaged document.
By default this functionality is disabled, but can be enabled in pipdefinitions.xml. See Configure pipdefinitions.xml file.
For response messages of dual-action PIPs the PipInstanceId and InReplyToTrackingId must be included in the service content. If included, the GlobalUsageCode, PipInstanceId, InReplyToTrackingId and InitiatingRoutingId values from the service content are used in the packaged RNIF message.
When enabled, the following field is parsed:
thisDocumentIdentifier/ProprietaryDocumentIdentifier
The location to parse can be modified in pipdefinitions.xml (see the following figure).
The following figure illustates DTD-based service contents.
|
|
The value of the ProprietaryDocumentIdentifier element should take the form of a colon-separated list of strings. The first string is the proprietary document ID. Optionally include:
GlobalUsageCode secondPipInstanceId thirdInReplyToTrackingId fourthInitiatingRoutingId fifthBlank fields are acceptable within the string. For example, to set only the proprietary document ID and pipInstanceId the string would look like:
Myid::12346
Where Myid is the proprietary document ID and 12346 is the PipInstanceId.
The GlobalUsageCode, PipInstanceId, InReplyToTrackingId and InitiatingRoutingId values from the outbound message are used in building the protocol headers in the packaged RNIF message.
Note that the PipInstanceId, GlobalUsageCode, InReplyToTrackingId and InitiatingRoutingId values are stripped from the service content that is packaged and produced to the trading partner. The identifier value is included in the packaged service content.
If enabled, the PipInstanceId, GlobalUsageCode, InReplyToTrackingId and InitiatingRoutingId are written to the received service content produced to integration. This enables back-end systems to know the values necessary for sending response documents for dual-action PIPs.
If enabled, the following field is parsed:
|
|
The location can be changed in pipdefinitions.xml. See the following figure: schema-based service contents.
|
|
The value of the Identifier element should take the form of a colon-separated list of strings. The first string is the identifier. Optionally include:
GlobalUsageCode secondPipInstanceId thirdInReplyToTrackingId fourthInitiatingRoutingId fifthBlank fields are acceptable within the string. For example, to set only the identifier and pipInstanceId the string would look like:
Myid::12346
Where Myid is the identifier value and 12346 is the PipInstanceId.
The GlobalUsageCode, PipInstanceId, InReplyToTrackingId and InitiatingRoutingId values from the outbound message are used in building the protocol headers in the packaged RNIF message.
Note that the PipInstanceId, GlobalUsageCode, InReplyToTrackingId and InitiatingRoutingId values are stripped from the service content that is packaged and produced to the trading partner. The identifier value are included in the packaged service content.
If enabled, the PipInstanceId, GlobalUsageCode, InReplyToTrackingId and InitiatingRoutingId are written to the received service contents produced to integration. This allows back-end systems to know the values necessary for sending response documents for dual-action PIPs.