Exprimental usage of SLA Quota and Rate in Oracle OCSG 

I got a question today, regarding how to keep a balance of sent and not sent requests for an Service Provider in Oracle OCSG 4.1 over time. 

Question:

"Suppose we allowed 50,000 SMSs/Month to SP and if he use 45000 then next month his limit should be 55000 (50000 + previous month balance). How we could accomplish above mention restriction? "

And the answer will be that I really don't think this is fully supported in the product. One approach will of course be to build a custom policy layer using interceptors. But I don't think its possible to handle by SP SLA restrictions only.

Do you have a possible solution for the issue, please post it to me and I will add it here. Contact This e-mail address is being protected from spambots, you need JavaScript enabled to view it .

White list

This blog post require from the reader to be familiar to the OCSG’s Partner Management Model and how to add and modify Service Level Agreements (SLAs). OCSG exposes a northbound ParlayX interface.

I got a question regarding how to utilize OCSG 4.1 policy control via SLA (Service Level Agreement) in Oracle Communications Services Gatekeeper (OCSG) 4.1, known as WebLogic Network Gatekeeper (WLNG) in older releases (WLNG 2.1. WLNG 2.2 and WLNG 3.0).

The issue was how to restrict one ServiceProvider to only send SMS on 5 different numbers. In other words, how to maintain a white list in SLA to accomplish it?

In earlier version of WLNG there was a problem in internal Policy Service with parsing arrays of recipients but that shall now be resolved in OCSG 4.0/4.1. The following is possible to setup on both application and ServiceProvider level.

The issue on the configuration step was to know how to fetch the addresses array. (If arg0.addresses doesn’t work, try parameters.addresses). Also, please remember to use tel: prefix on addresses.

(Imran Raza Khan, thank you!)

Blacklist

We can also invert the behavior if this restriction. Say that we would like to restrict the provider or application and not let him send SMSs to alarm numbers. In that case, this restriction can be added something like this:

Restrict TPS

It is also possible to restrict the number of transactions per time unit. This is handled via methodRestrictions element. In the example below we have a complete service contract and we limit the provider to only send 10 requests per 8 second time window. Messages above this rate are rejected. In the example we have also added a day-restriction of maximum 1000 messages, this as a second protection-level.

Blacklist method

There is also one variant where you can exclude one or several methods from the interface exposed to providers. Only simple way is to use the blacklist method tag. In the example below we restrict the usage of sendSms to network, but the application can still receive text messages, since we don’t have any restriction expressed for this.

More Policy options

You have of course also many other ways that you can restrict and control traffic in OCSG. It’s quite easy to experiment with these, just modify and test!

Here are some samples of what to modify on SP/APP group SLA level:
• Start and end date of the contract.
• Which Service Capabilities the service Provider Group is allowed to use.
• Guaranteed number of requests per time-interval for a specific method.
• Maximum number of requests per time-interval for a specific method.
• Access to individual methods.
• Which currencies to use in the Charging service.
• Possible charging amounts or charging indicators when sending SMSs and MMSs.
• Maximum size of SMSs and MMSs
• Content types to be allowed in MMSs (MIME-types).
• If allowed to listen for mobile originating messages or message delivery notifications.
• If allowed to use USSD or SMS in message based user interaction.
• Maximum number of concurrent voice calls.
• Maximum number of participants in a call (legs).
• Which state transitions (ANSWER , ALERTING , ADDRESS_ANALYSED , etc..) for a call that can be distributed to an application.
• If allowed to read or read and write subscriber profiles.

Comments? Contact This e-mail address is being protected from spambots, you need JavaScript enabled to view it

SoapUI has now released version 2.5, The REST Release, introduces support for testing of RESTful services, including Inspection, Invocation, Functional Tests, Assertions and LoadTests. Download it today or read a more detailed summary of all new features here.

Redstone has increased the local visibility in Karlstad – Sweden, by putting up a 3,5 meter wide Redstone-sign at our Office house! This is a natural step to improve the awareness of Redstone and strengthen the Redstone-Brand.

Redstone has also arranged to add a sign for the local Oracle office which we added at the same moment. See pictures from today when adding both signs at the front wall. :-)

Starting the work.

Oracle sign in place first.

Both Redstone and Oracle sign in place, almost dark now.

Alfa Neon has manufactured the signs.