The TCAP message and TCAP component hierarchies represent the TCAP messages sent and received between the IPSMGW and remote TC-Users. These objects are POJOs (Plain Old Java Objects) that may be created and updated as needed and stored in CMP fields.
TCAP Messages - The Dialog Message Hierarchy
The IPSMGW receives events from the CGIN MAP resource adaptor and builds message objects the correspond to whole TCAP messages received on the wire.
|   | See: CGIN Connectivity Pack to learn more about SS7 interfaces in the Rhino TAS platform. | 
 
At the top of the hierachy is the DialogTCAPMessage interface, which has operations that you use to:
- 
find out if the message is a TC-Begin,TC-ContinueorTC-End
- 
find out if the message is a DialogOpenRequest,DialogOpenAccept,DialogOpenRefuse,DialogUserAbort,DialogProviderAbortor aDialogMessage
- 
see if the message contains any components. 
The concrete classes include:
- 
DialogOpenRequestTcapMessage— The initial message for a new dialog (always a TC-Begin). An open request includes source and destination address, a TCAP Application Context to use for the new dialog and may optionally include components.
- 
DialogOpenAcceptTcapMessage— A first response on a new Dialog, which indicates the remote TC-User has accepted the new Dialog (a TC-Continue or a TC-End). An open accept may optionally include components.
- 
DialogOpenRefuseTcapMessage— A first response on a new Dialog, which indicates the remote TC-User has refused the new Dialog (always a TC-End). An open refuse contains a refuse reason, (optionally) a peer abort cause and (optionally) a suggested alternative TCAP Application Context
- 
DialogUserAbortTcapMessage— A message indicating the fatal ending of a Dialog (always a TC-End).
- 
DialogProviderAbortTcapMessage— A message indicating the fatal ending of a Dialog related to the local TC provider (always a TC-End).
- 
DialogMessageTcapMessage— Every other type of message received on a Dialog (a TC-Continue or a TC-End). This type of message may optionally include components.
|   | The  | 
|   | See Using The Leg Manager in the IP-SM-GW SDK guide to learn more about using these objects during the development of your own features. | 
Storing TCAP Messages in CMP fields
The TCAP messages are POJOs (Plain Old Java Objects) that may be created and updated as needed and stored in CMP fields. Whilst these objects are all Serializable it is far more efficient to use the DialogTcapMessageCodec as in the following example.
package com.opencloud.sentinel.ipsmgw.myfeature;
import com.opencloud.rhino.cmp.codecs.DatatypeCodecType;
import com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage.DialogTcapMessage;
import com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage.persist.DialogTcapMessageCodec;
public interface MyFeatureCMP {
    /**
     * Set the 'MyTcapMessage' cmp field
     * @param message cmp field value
     */
    @DatatypeCodecType(DialogTcapMessageCodec.class)   void setMyTcapMessage(DialogTcapMessage message);
    void setMyTcapMessage(DialogTcapMessage message);  /** @return 'MyTcapMessage' cmp field value */
    DialogTcapMessage getMyTcapMessage();
    /** @return 'MyTcapMessage' cmp field value */
    DialogTcapMessage getMyTcapMessage();  /** @return true if 'MyTcapMessage' cmp field is set */
    boolean hasMyTcapMessage();
    /** @return true if 'MyTcapMessage' cmp field is set */
    boolean hasMyTcapMessage();  /** Clear 'MyTcapMessage' cmp field */
    void resetMyTcapMessage();
    /** Clear 'MyTcapMessage' cmp field */
    void resetMyTcapMessage();  }
}|  | DatatypeCodecTypeannotation tells Rhino to useDialogTcapMessageCodecto encode/decodeDialogTcapMessageobjects | 
|  | setoperation for theMyTcapMessageCMP field | 
|  | getoperation for theMyTcapMessageCMP field | 
|  | (optional) hasoperation for theMyTcapMessageCMP field | 
|  | (optional) resetoperation for theMyTcapMessageCMP field | 
|   | See: Rhino TAS > CMP Field Enhancements to learn more about using CMP fields in Rhino | 
 
