2 Message Formats

This topic explains the different message formats of the data exchange between Oracle Flexcube Investor Servicing and the external systems.

Introduction

Data exchanged between Oracle Flexcube Investor Servicing (FCIS) and the external systems will be in the form of XML messages. These XML messages are defined in FCIS in the form of XML Schema Documents (XSD) and are referred to as FCIS formats. An XML Schema is uniquely identified by its Namespace and its Root Element (root node). The root node for XSDs of gateway messages will be generated as per the following pattern:
  • <OPERATION>_<MESSAGE EXCHANGE PATTERN>_REQ
  • <OPERATION>_<MESSAGE EXCHANGE PATTERN>_RES, Where <OPERATION> refers to an Oracle Flexcube Investor Servicing operation like CREATEUNITHOLDER.
  • <MESSAGE_EXCHANGE_PATTERN> refers to the request and response message patterns exchanged. The Message Pattern is of the following types:
    • Full Screen (FS) -This indicates that the payload will contain all the elements on the corresponding Oracle Flexcube Investor Servicing screen.
    • Input Only (IO) - This indicates that the payload will contain the only input elements on the correspondingOracle Flexcube Investor Servicing screen.
    • Primary Key (PK): This indicates that the payload will contain only the Primary Key elements of the corresponding Oracle Flexcube Investor Servicing screen.

<MESSAGE_EXCHNAGE_PATTERN> is a combination of message patterns.

The <MESSAGE_EXCHNAGE_PATTERN> available in Oracle Flexcube Investor Servicing is shown below:
  • FSFS - Full Screen Request and Full Screen Response
  • IOPK - Input Only Request and Primary Key Response
  • IOFS - Input Only Request and Full Screen Response
Non-Query Formats

For instance, consider the Operation CREATEUNITHOLDER.

The root node of messages under this operation will be as under:

CREATEUNITHOLDER_FSFS_REQ

Figure 2-1 CREATEUNITHOLDER_FSFS_REQ


Description of Figure 2-1 follows
Description of "Figure 2-1 CREATEUNITHOLDER_FSFS_REQ"

CREATEUNITHOLDER_FSFS_RES

Figure 2-2 CREATEUNITHOLDER_FSFS_RES


Description of Figure 2-2 follows
Description of "Figure 2-2 CREATEUNITHOLDER_FSFS_RES"

CREATEUNITHOLDER_IOPK_REQ

Figure 2-3 CREATEUNITHOLDER_IOPK_REQ


Description of Figure 2-3 follows
Description of "Figure 2-3 CREATEUNITHOLDER_IOPK_REQ"

CREATEUNITHOLDER_IOPK_RES

Figure 2-4 CREATEUNITHOLDER_IOPK_RES


Description of Figure 2-4 follows
Description of "Figure 2-4 CREATEUNITHOLDER_IOPK_RES"

Query Formats

For instance, consider the Operation QUERYUNITHOLDER.

The root node of messages under this operation will be as under:

QUERYCUNITHOLDER_IOFS_REQ

Figure 2-5 QUERYCUNITHOLDER_IOFS_REQ


Description of Figure 2-5 follows
Description of "Figure 2-5 QUERYCUNITHOLDER_IOFS_REQ"

QUERYCUNITHOLDER_IOFS_RES

Figure 2-6 QUERYCUNITHOLDER_IOFS_RES


Description of Figure 2-6 follows
Description of "Figure 2-6 QUERYCUNITHOLDER_IOFS_RES"

Oracle Flexcube Investor Servicing Envelope

A standard gateway message in the Oracle Flexcube Investor Servicing Envelope contains two main components namely:
  • FCUBS_HEADER – This is a node that forms the header of the FCUBS Envelope. The tags under the header portion of a message will identify a partner system, a service, an operation, user, branch, etc. These tags are constant across all messages.
  • FCUBS_BODY – This node contains the actual payload of a message. The contents of this node will vary for each message.
FCUBS HEADER
The tags under FCUBS HEADER have been described in below table:

Table 2-1 FCUBS HEADER

Tags Description
SOURCE

This indicates the name of the External system that is the source of the message.
UBSCOMP

This indicates the Oracle Flexcube Investor Servicing component of the message - whether FCIS or FCUBS.

MSGID

This unique ID identifies each message – incoming or outgoing in Oracle Flexcube Investor Servicing. Every message will have a distinct message ID

CORRELID

This is the id using which any system which has sent a request to FCUBS can correlate to the response. In the External system maintenance, the correlation pattern can be configured for each external system.

It can be maintained that either the MSGID or the CORRELID of the request message is returned back as the CORRELID in the response message. Depending on this maintenance, Oracle Flexcube Investor Servicing will set either theMSGID or the CORRELID of the request message in the response message.

USERID

For request messages, this ID is used to submit message requests. Oracle Flexcube Investor Servicing will process this request using this id.

For response messages, the value of this will be ‘null’.

BRANCH

This indicates the Oracle Flexcube Investor Servicing Branch Code where the request message needs to be processed. If the BRANCH is missing in the header, request message will be transmitted and processed in Head Office branch.

MODULEID

This indicates the module ID.
SERVICE

This provides details on the various services of Oracle Flexcube Investor Servicing.

For every incoming message in Oracle Flexcube Investor Servicing, the service name is mandatory.

OPERATION

This indicates the functional operation.
SOURCE_OPERATION

This indicates the functional operation as registered in Oracle Flexcube Investor Servicing.

SOURCE_USERID

This is the User ID with which the request message was invoked from the SOURCE.

DESTINATION

For incoming messages, the destination will be Oracle Flexcube Investor Servicing.

For response messages, system will populate the SOURCE of the request message as DESTINATION.

MULTITRIPID

This is a unique id which indicates overrides.
FUNCTIONID

This indicates the Oracle Flexcube Investor Servicing Function ID

ACTION

This indicates the action type.
MSGSTAT

This indicates whether the transaction is a SUCCESS or FAILURE.

PASSWORD

This indicates the password.
ADDL

This is used to send additional parameters i.e. parameters not available in Oracle Flexcube Investor Servicing.

FCUBS HEADERType

The image represents the node of FCUBS_HEADERType is as shown below:

Figure 2-7 FCUBS HEADERType


Description of Figure 2-7 follows
Description of "Figure 2-7 FCUBS HEADERType"

FCUBS BODY

The FCUBS_BODY will contain the actual payload to perform the respective transaction. The contents of the payload will vary for each operation.

The following snapshot shows a sample FCUBS_BODY of QUERYUNITHOLDER operation:

Figure 2-8 FCUBS_BODY of QUERYUNITHOLDER


Description of Figure 2-8 follows
Description of "Figure 2-8 FCUBS_BODY of QUERYUNITHOLDER"

Nodes for Error and Warning response

The FCUBS_BODY will contain additional nodes for error and warning responses.

The image represents the node for error response is as shown below:

Figure 2-9 Nodes for Error Response


Description of Figure 2-9 follows
Description of "Figure 2-9 Nodes for Error Response"

The image represents the node for warning response is as shown below:

Figure 2-10 Nodes for Warning Response


Description of Figure 2-10 follows
Description of "Figure 2-10 Nodes for Warning Response"

The nodes for error and warning responses have been described in the below table:

Table 2-2 Nodes for Error and Warning Response

Nodes for Error Warning Response
FCUBS_ERROR_RESP

The error response message will be sent from Oracle Flexcube Investor Servicing when errors are raised in a transaction. The error response will have another tag ERROR within it.

ERROR

The ERROR node will have tags for error code and error description. The ERROR node will be generated for each error raised by FCIS.

FCUBS_WARNING_RESP

The warning response message will be sent when overrides are raised in a transaction. The Warning response will have another tag WARNING within it.

WARNING

This node will have tags for warning code and warning description. The WARNING node will be generated for each override raised by FCIS.

FCIS NOTIFICATION

The notification messages are generated in a standard format.

The notification messages will consist of two main components:
  • FCUBS_NOTIF_HEADER – This forms the header portion of a notification message. This contains a standard set of tags that can identify a notification. These tags are constant across all notification messages.
  • FCUBS_NOTIF_IDENTIFIER – This will identify the maintenance records based on the information provided under this node. The contents of this node will vary for each notification.
The image represents the node of FCUBS NOTIFICATION is as shown below:

Figure 2-11 FCUBS NOTIFICATION


Description of Figure 2-11 follows
Description of "Figure 2-11 FCUBS NOTIFICATION"

FCIS NOTIFICATION HEADER
The image represents the node of FCIS NOTIFICATION HEADER is as shown below:

Figure 2-12 FCIS NOTIFICATION HEADER


Description of Figure 2-12 follows
Description of "Figure 2-12 FCIS NOTIFICATION HEADER"

The tags under FCIS NOTIFICATION HEADER have been described in the below table:

Table 2-3 FCIS NOTIFICATION HEADER

Tags Description
SOURCE

This indicates the name of the External system or the source of the message.
MSGID

This is the unique reference number generated by Oracle Flexcube Investor Servicing.

NOTIF_REF_NO.

This unique reference number identifies each notification message generated in Oracle Flexcube Investor Servicing.
BRANCH

This indicates the branch in which notification has been triggered.
NOTIF_CODE

This indicates the code for the notification that has been triggered.
DESTINATION

For incoming messages, the DESTINATION should be Oracle Flexcube Investor Servicing. For response messages, system will populate the SOURCE of the request message as DESTINATION.

MODULEID

This indicates the module ID.

Refer Service Documentation available under Gateway for details about each message.