Using the Activity Object

HP OpenCall SS7 ISUP provides a way to optimize HP OpenCall SS7 ISUP API calls through the ActivityObject. Implementing the ActivityObject takes advantage of the callback methods provided by this object.

Criteria for Choosing to Implement the Activity Object

If you do not use the Activity Object

If you choose not to use the ActivityObject, the application must perform the following tasks.

In case of outbound flow-control the application must regularly call the IsupProbe::send() method to know if the flow-control condition is still present
The application must regularly call the IsupProbe::receive() method to receive all inbound ISUP messages.

If you Implement the Activity Object

If you choose to implement an ActivityObject the HP OpenCall SS7 ISUP API provides the application with following information:

the number of ISUP messages waiting to be received through the recvActivity() method
the end of an outbound flow-control condition through the sendPossible() method
any change of the MTP connection status through the cnxStatus() method.

How to use the Activity Object

You can derive an activity object mechanism for IsupSMProbe and IsupBPProbe objects. The aim of the mechanism must be to inform the probe object(s) that primitives are waiting to be received by the application. The mechanism must also inform the probe object(s) whether it is possible to send ISUP messages and primitives, and the status of the connection.

An ActivityObject class is defined by IsupSMProbe and IsupBPProbe. These classes contain the following virtual methods:

Table 12-1 Activity Methods

Return Type	Method	Arguments
virtual void	recvActivity()	`(IsupSMProbe *aProbe, int nbOfRecvToDo)=0;`
virtual void	recvActivity()	`(IsupBPProbe *aProbe, int nbOfRecvToDo)=0;`
virtual void	sendPossible()	`(IsupSMProbe * aprobe)=0;`
virtual void	sendPossible()	`(IsupBPProbe * aprobe)=0;`
virtual void	cnxStatus()	`(IsupSMProbe * aProbe, ISUP::CnxStatus aStatus)=0;`
virtual void	cnxStatus()	`(IsupBPProbe * aProbe, ISUP::CnxStatus aStatus)=0;`

Redefining the Activity Methods

The application can derive its own ActivityObject classes from the provided parent class. You can then redefine the ActivityObject methods, using the same arguments.

recvActivity()

From the inbound path, the IsupSMProbe::recvActivity() and IsupBPProbe::recvActivity() methods must provide the number of primitives waiting to be received by a specific probe object.




	NOTE: It must not receive the waiting primitives.

sendPossible()

From the outbound path, the IsupSMProbe::sendPossible() and IsupSMProbe::sendPossible() methods must indicate whether it is possible to send messages from a specific probe object to the network.

cnxStatus()

The cnxStatus() must indicate the status of the connection with the SS7 stack, such as switchover or the connection has been closed.

Example 12-4 Redefining the recvActivity() for an IsupSMProbe Object.

//  activity object inheriting from IsupSMProbe: definition and
// implementation 
 
class MyActivityObject: public IsupSMProbe::ActivityObject
{ 
 void recvActivity(IsupSMProbe * aProbe, int nbOfRecvToDo);
 void sendPossible(IsupSMProbe * aProbe);
 void cnxStatus(IsupSMProbe * aProbe, ISUP::CnxStatus aStatus);
};
 
// List of Pending messages for each active ProbeList_of_p<RecvToDo> *listOfRecvToDo;
//---------------------------------------------------------------------
//   Implementation of callback method MyActivityObject::recvActivity()
//     << DO NOT CALL ‘receive’ in this callback method !! >>
//
//---------------------------------------------------------------------
void MyActivityObject::recvActivity(IsupSMProbe * aProbe, int nbOfRecvToDo)
{
  RecvToDo * recvToDo;
 
      recvToDo= new RecvToDo (aProbe, nbOfRecvToDo);
      if (listOfRecvToDo == NULL)
      listOfRecvToDo = new List_of_p<RecvToDo>;
    listOfRecvToDo->put (recvToDo);
}