One last day before my summer vacation begins…I had been hoping to have had time to write about actual code here, but I have been busy writing actual code instead.
A very early version of this code is uploaded to the sample_applications directory in this repository.
It is an http adapter which is supposed to eventually replicate most of the Content Gateway HTTP interface so that some of you users can drop it in place of your current CGW Provider Server and avoid the hassle of updating your own application. That is the intention – it is too early to tell how well this would work. If you can avoid coding work, there’ll be plenty of installation and configuration tasks anyway.
What does it Do? Not much now…
I barely got sending simple text messages through it to work. There has been virtually no actual testing yet. If you are reading this blog, you are hopefully a programmer. Then you might be able to get the code to compile and run. Not sure if it is worth your while for anyone else at this point. Maybe you can learn something from the code about how to use the Opaali API. The code worked for me, at least.
At this point the http adapter has pretty much the same functionality as the send.sh script I released earlier in this repository. It is my intention to add functionality to both, as soon as I can, but don’t hold your breath - I’ll be away for a month or so, first.
What does it look like?
I initially started to write this as an example of how you can use the Opaali API from your Java code. So the emphasis is on code clarity and not on performance. (Although, already there was talk about using this in production, in-house…) I chose to use a templating system where the template looks like the http request examples in the official Opaali API documentation.
Here is an example from the Messaging API documentation:
And this is the template from my code:
String[] MTTemplate = {
// API request for sending MT messages
"POST https://${API_HOST}/production/messaging/v1/outbound/${SENDERADDRESS_ENCODED}/requests HTTP/1.1",
"Host: ${API_HOST}",
"Content-type: application/json",
"Accept: application/json",
"Authorization: Bearer ${ACCESS_TOKEN}",
"",
"{",
" \"outboundMessageRequest\":",
" {\"address\":[${RECIPIENTLIST}],",
" \"senderAddress\":\"${SENDERADDRESS}\",",
" ${MESSAGE}",
" ${SENDERNAMESTRING}${CHARGINGINFO}${DLRREQUESTSTRING}${CLIENTCORRELATOR}",
" }",
"}"
};
The idea was that you can modify/extend the code easily based on the examples in the API reference documentation. And maybe it will be easier to understand how the code works.
Incidentally, there already was Java example code in the Resources section of the Opaali Portal. That code is much more professionally written than mine and it has a build script. It beautifully implements information hiding so that you cannot easily tell how the Opaali API calls are made at the low level. Which kind of makes it rather useless as an example of how to call Opaali API from your own code…
If it works today, will it work next week?
If you already have an Opaali account, you should have received a message about the service break next week (19.6.-20.6.2017). The Opaali platform software is to be upgraded from rel3 to rel4. While there aren’t any API changes (other than new functionality being added) there are some major changes in the implementation underneath to improve performance and reliability. My code has been tested to work on rel3, but I haven’t tested it on rel4 yet. Should something in your code break after this upgrade, if you cannot resolve it by yourself, you can always contact opaali-tuki@teliacompany.com for help.
JPLa is a member of the Content Gateway (CGW) to Opaali migration team, specialising in programming related issues and API usage.