Time flies…my previous update to this blog seems to have been exactly nine months ago today. Most of that time I have been busy writing code related to migrating some internal systems. In fact, one of them was finally migrated to Opaali earlier this week. There is only a couple more left, and I believe all the external customers were migrated from Content Gateway to Opaali already before the summer.
Although this blog has not been actively updated anymore, there are still a couple of things that need to be documented better - I’ll try to do that while I still can.
Not using international number format may cost more!
You may have noticed that sending messages to local numbers (040… and so on, you know) works without the “tel:” prefix followed by the number in international format (+35840… you knew that, too). This is so convenient that even I have been doing this.
But it turns out that Opaali thinks the message is going outside of Telia’s own network – it will be delivered, but it will cost more!
Because of this, some Opaali Service Providers have this week received email with the following message:
We have noticed that Your application <application name> use Opaali wrong way on case of MT sms sending. Number format must be “tel:+358”- started when sending to Finnish numbers and on case of other locations target country code must be use. We can see sending on format “0401234567” which is not supported on Opaali and might cause extra expenses as number don’t be recognized as Telia subscription. Please repair sending side as soon as possible.
Documentation where number format is clearly shown: https://developer.opaali.telia.fi/resources
So you are urged to fix this (I don’t know how long they will wait – I expect them to be reasonable with this, but if you keep ignoring them they may eventually cut your service off!)
Restrictions to access_token fetching
I have earlier shown code examples where the access_token is retrieved every time before sending the actual message. This is OK, if you send messages seldom enough. My send.sh script does it this way.
But if too many applications keep doing this, it has a negative effect on the performance of Opaali as a whole. To improve the performance, the platform maintainers have started enforcing the rule that you should not renew your token before it is about to expire. Initially those who fetch the token too frequently have been contacted and asked to change their implementation. If needed, there will be a hard limit enforced and if the overall Opaali system performance keeps degrading the limit will become tighter.
I should probably update my send.sh script and write about it in a future blog post.
Using http_adapter in migrating old services
Along with writing code for that internal system, that was migrated earlier this week, most of my spring was spent on enhancing the http_adapter so that it could be used in migrating some of the other internal systems. I have already almost forgotten how to use this new functionality, so I at least need to write another blog post documenting them.
Binary messaging extensions
Some time last winter (…I can’t even remember when, exactly…oh, looks like it was in R4SP2) Opaali got an update to binary message handling. The OMA Standard, which OpaaliAPI is based on, does not define how incoming binary messages should be handled. Originally they were treated as text in Opaali, but as Content Gateway already supported receiving binary messages, extended binary message support was implemented in OpaaliAPI. At the same time, the sending side received a couple of new extensions, too. I’ll write more about this in a separate blog post to come.
Finally
As the migration from Content Gateway to Opaali has been getting closer to its completion, my role in this has also been becoming smaller. I am not part of the official Opaali support channel, but I have been consulting them in various support cases. As I said, I’m intending to write at least a couple more posts here about details needing more documentation.
JPLa is a member of the Content Gateway (CGW) to Opaali migration team, specialising in programming related issues and API usage.