Package org.jainslee.resources.diameter.sh

Diameter Sh Resource Adaptor Types based on following 3GPP specifications:

3GPP Technical Specification 29.329 v7.8.0.

3GPP Technical Specification 29.329 v8.8.0.

3GPP Technical Specification 29.329 v9.4.0.

3GPP Technical Specification 29.329 v10.1.0.

3GPP Technical Specification 29.329 v11.6.0.

3GPP Technical Specification 29.329 v12.6.0.

The ShProviderFactory provider factory interface provides methods to obtain a appropriate 3GPP version of provider interface (the same as configured in resource adaptor entity).

SBBs can obtain a ShProviderFactory instance via JNDI after specifying an appropriate <resource-adaptor-entity-binding> entry in the SBB deployment descriptor.

Following provider interfaces provide methods to obtain a factory class to create Diameter Credit Control AVPs and Diameter messages.

For Sh version 7.8.0 : org.jainslee.resources.diameter.sh.v780.ShProvider

For Sh version 8.8.0 : org.jainslee.resources.diameter.sh.v880.ShProvider

For Sh version 9.4.0 : org.jainslee.resources.diameter.sh.v940.ShProvider

For Sh version 10.1.0 : org.jainslee.resources.diameter.sh.va10.ShProvider

For Sh version 11.6.0 : org.jainslee.resources.diameter.sh.vb60.ShProvider

For Sh version 12.6.0 : org.jainslee.resources.diameter.sh.vc60.ShProvider

These interfaces contain all the methods that can be used by a SLEE service.

SBBs can obtain instance of one of provider interfaces calling one of methods: getShProviderV780() getShProviderV880() getShProviderV940() getShProviderVa10() getShProviderVb60() getShProviderVc60() These methods return either instance of ShProvider if resource adaptor entity is configured to support corresponding 3GPP version or null if resource adaptor entity is not configured to support such 3GPP version. SBB must use two packages corresponding to choosen 3GPP version:

For 3GPP 7.8.0: org.jainslee.resources.diameter.sh.v780 and org.jainslee.resources.diameter.sh.types.v780

For 3GPP 8.8.0: org.jainslee.resources.diameter.sh.v880 and org.jainslee.resources.diameter.sh.types.v880

For 3GPP 9.4.0: org.jainslee.resources.diameter.sh.v940 and org.jainslee.resources.diameter.sh.types.v940

For 3GPP 10.1.0: org.jainslee.resources.diameter.sh.va10 and org.jainslee.resources.diameter.sh.types.va10

For 3GPP 11.6.0: org.jainslee.resources.diameter.sh.vb60 and org.jainslee.resources.diameter.sh.types.vb60

For 3GPP 12.6.0: org.jainslee.resources.diameter.sh.vc60 and org.jainslee.resources.diameter.sh.types.vc60

Events

The Diameter Sh resource adaptor fires the following eight events for each supported 3GPP version. Three of the events are responses to requests sent to a server node and three of the events are requests initiated by a client. The last two events are fired when the server sends a Push-Notification-Request messageto the client, or on receipt of an acknowledgement to a Push-Notification-Request. For Sh version 7.8.0.

For Sh version 8.8.0. For Sh version 9.4.0. For Sh version 10.1.0. For Sh version 11.6.0. For Sh version 12.6.0.

Example

This example uses the methods on the ShProvider interface to create and attach to an activity, then create and send a User-Data-Request: 
    // Create and attach to the Sh activity
    ShClientActivity shClientActivity = shProvider.createShClientActivity();
    ActivityContextInterface shACI = shACIFactory.getActivityContextInterface(shClientActivity);
    shACI.attach(getSbbLocalObject());

    // Create and send the UDR
    ShMessageFactory messageFactory = shProvider.getMessageFactory();
    UserIdentity userIdentity = messageFactory.createUserIdentity();
    userIdentity.setPublicIdentity(address);
    UserDataRequest userDataRequest = messageFactory.createUserDataRequest(userIdentity, DataReference.IMS_PUBLIC_IDENTITY);
    userDataRequest.setDestinationHost(new DiameterIdentity("sh-server"));
    userDataRequest.setDestinationRealm(new DiameterIdentity("opencloud"));
    shClientActivity.sendUserDataRequest(userDataRequest);

The following code fragment shows an event handler for the User-Data-Answer which extracts the S-CSCF Name from the unmarshalled User-Data AVP. 

    public void onUserDataAnswer(UserDataAnswer uda, ActivityContextInterface aci) {
        if(uda.getResultCode() == DiameterResultCode.DIAMETER_SUCCESS) {
            ShData shData = uda.getUserData().getShData();
            String scscfName = shData.getShIMSData().getSCSCFName();
            // use scscfName for something
        }
    }

Creating User-Data Example

To create the Sh-Data XML document for the User-Data AVP, use the UserDataObjectFactory obtained from the ShMessageFactory. The following code fragment shows the creation of a Profile-Update-Request that changes a subscriber's S-CSCF Name setting. 
    ShMessageFactory messageFactory = shProvider.getMessageFactory();
    UserIdentity userIdentity = messageFactory.createUserIdentity();
    userIdentity.setPublicIdentity(address);

    UserDataObjectFactory userDataFactory = messageFactory.getUserDataObjectFactory();

    ShIMSData shIMSData = userDataFactory.createShIMSData();
    shIMSData.setSCSCFName(scscfName);

    ShData shData = userDataFactory.createShData();
    shData.setShIMSData(shIMSData);

    ProfileUpdateRequest profileUpdateRequest =
            messageFactory.createProfileUpdateRequest(userIdentity, DataReference.S_CSCFNAME,
                                                            messageFactory.createUserData(shData));

Note: The synchronous API should only be used for simple test services that are not expected to run at high loads. The resource adaptor does not currently implement timeouts for synchronous requests, so SBBs may block indefinitely. Services that use the synchronous model also do not scale well.