Back-End Applications Interface

A Back-End Applications Interface

This appendix lists the message properties supported by Oracle SOA Suite for healthcare integration.

The appendix contains the following topics:

A.1 Mapping SCA Normalized Message Properties

The SCA message properties can be mapped to JMS adapter properties.

Table A-1 maps the SCA normalized message properties to the JMS adapter properties.

Table A-1 Healthcare IP_MESSAGE_TYPE to AS11 SCA Normalized Message Property Mapping

SCA	JMS
hc.messageId	MSG_ID
hc.replyToMessageId	INREPLYTO_MSG_ID
hc.fromEndpoint	FROM_ENDPOINT
hc.toEndpoint	TO_ENDPOINT
hc.action	ACTION_NAME
hc.documentTypeName	DOCTYPE_NAME
hc.documentProtocolVersion	DOCTYPE_REVISION
hc.messageType	MSG_TYPE
hc.conversationId	-
hc.interfacesequenceId	INTERFACE_SEQUENCE_ID
hc.interfacesequencediscardid	INTERFACE_SEQUENCE_DISCARD_ID
hc.groupCount	INTERFACE_GROUP_COUNT
-	INTERFACE_GROUP_POSITION

A.2 Normalized Message Properties

Header manipulation and propagation are key business integration messaging requirements. Like other SOA components such as Oracle BPEL Process Manager, Oracle Mediator, and Oracle JCA, Oracle SOA Suite for healthcare integration relies on header support to solve integration requirements. For example, you can preserve a file name from the source directory to the target directory by propagating it through message headers.

Normalized messages have two parts, properties and payload. Typically, properties are name-value pairs of scalar types. To fit the existing complex headers into properties, properties are flattened into scalar types.

Table A-2 lists the predetermined properties of a normalized message for Oracle SOA Suite for healthcare integration.

Table A-2 Properties for Oracle SOA Suite for healthcare integration

Property Name	Propagable (Yes/No)	Direction (Inbound /Outbound)	Data Type	Range of Values	Description
hc.conversationId	No	Both	String	-	The ID used to relate the message to the message response
hc.documentDefinitionName	No	Both	String	-	The document definition
hc.documentProtocolName	No	Both	String	-	The document protocol
hc.documentProtocolVersion	No	Both	String	-	The document version
hc.documentTypeName	No	Both	String	-	The document type, for example, 850 for an EDI X12 document
hc.fromEndpoint	No	Inbound	String	-	Endpoint name from which an inbound message was received.
hc.messageId	No	Both	String	-	A unique message ID, not directly related to ECID. (ECID information is stored in the B2B AppMessage table.)
hc.messageType	No	Both	String	-	Message type values are: Request = 1 Response = 2 Functional Ack = 9
hc.replyToMessageId	No	Both	String	-	The message ID to which the sending message is replying
hc.toEndpoint	No	Outbound	String	-	The endpoint name to which the outbound message is delivered.
`hc.interfacesequenceId`	No	Both	String	-	For inbound interfaced sequenced messages, this header is delivered to the back end. The composite or application must be designed to read this header and pass the same header to the outbound message. The outbound message must include this header in order to be recognized as an interface sequenced message. This information is used by the sequencing framework to correlate the message.
`hc.interfaceGroupCount`	No	Outbound	String	-	This header is relevant for the outbound message when the message is fanned out. (A source message is sent to multiple destinations) The composite must populate this header with the number of fan-outs for a given source message when enqueuing the message to the HC adapter.
`hc.interfacesequencediscardid`	No	Outbound	String	-	Serves as a dummy substitute for an outbound message used to determine whether all messages for the group have arrived. For example, a message has to be split into two flows for the lab and pharmacy. Based on some criteria in the lab, it is determined the message should not be delivered. To achieve this, the user must send a message to Healthcare with a `GROUP_COUNT` of "2" along with the `INTERFACE_SEQUENCE_DISCARD_ID` flag. The pharmacy flow delivers the message normally with a `GROUP_COUNT` of "2" and the `INTERFACE_SEQUENCE_ID` flag set. Based on the presence of the `INTERFACE_SEQUENCE_DISCARD_ID` flag, Healthcare determines if the lab message should be processed. The message for count matching is used for the group and then the message is ignored. If `INTERFACE_SEQUENCE_DISCARD_ID` is present alone, it continues to discard the entire message set.
`INTERFACE_GROUP_POSITION` (JMS Header)	No	Outbound	String	-	Use the `INTERFACE_GROUP_POSITION` to determine the order of messages when multiple messages within a group (`INTERFACE_GROUP_COUNT`) are intended for the same endpoint and ordering is enforced among these messages. The message to be delivered first is set with the value "1" and the next message is set with the value "2". The messages are delivered in that order regardless of when these messages are received by the outbound Healthcare adapter.

A.3 Configuration Properties in Fusion Middleware Control

The properties listed in the following table can be set in Oracle Enterprise Manager Fusion Middleware Control.

Table A-3 Properties in Oracle Enterprise Manager Fusion Middleware Control

Property	Description
`hc.sequencedEndpoints`	Common separator values are ALL,<EP_1>,<EP_2>. Any endpoints after ALL will not be sequenced. In this example, both <EP_1> and <EP_2> will have sequencing turned off.
`hc.queryOnLoad`	This is true/false; default is true. When this flag is set to false, Healthcare does not automatically query the database when the report pages are loaded for the first time. If the flag is not added to Enterprise Manager, it is defaulted to true so the behavior is consistent with previous implementations.
`hc.faForPFF`	This is true/false; default is false.
`hc.retryIntervalForPFF`	This is a numeric value; the default is 0. The interval, specified in minutes, after which Healthcare attempts to resend a message. Healthcare tries to resend the message if the status of the message is not Complete.
`hc.retryCountForPFF`	This is a numeric value; the default is 0. The number of times that Healthcare tries to send the message.
`hc.jmsAndDBSameTxn`	If this property is set to true, then the commit to the JMS will be on the same transaction as the database. If the database is rolled back, then the message is not committed to JMS as well.
`hc.HCMode`	If this property is set to true, then inserting the FA_RETRY_TIMEOUT mechanism will be handles differently by another thread so that the following exception will not be seen in the log: `B2B_ServiceEngine.FA_RETRY_TIMEOUT_0A9B961B149768C4DA40000059B3B986) referenced by the trigger does not exist`
`hc.customNACK`	This property supports NACK for a custom acknowledgement in the following scenarios: When a callout exception occurs in the inbound scenario, Healthcare returns the custom nack content defined in this property. When it fails to enqueue to B2B_EVENT_QUEUE in the inbound scenario, Healthcare returns the custom nack content defined in this property. In either scenario, if nothing is defined, the default of “NACK” is returned.