Build a workflow using APIO as a replacement for Loki provisioning portal in Cisco BroadWorks UC
It’s been a busy time at Netaxis. Very busy with lovely customers wanting our help with their Cisco BroadWorks Unified Communications projects. BroadWorks is the swiss army knife of UC platforms: extremely powerful yet complex to operate and integrate. One of the major challenges our customers have is finding the right balance between automation and offering enough flexibility to their customers. At Netaxis we strongly believe in customer empowerment. Giving your customers all capabilities to manage their own environment will allow you to limit your integration efforts while giving your customers a maximum in flexibility.
However, a UC ecosystem is complex containing many elements – how do you integrate all those elements? And what is a Loki portal or replacement if it just touches one box of the entire solution?
This problem is the main reason (see our first blogpost about LOKI replacement) why Netaxis decided to fully rebuild our legacy, monolithic portal application and move to an API first design. By moving all business logic into a flexible API driven backend, we dramatically simplify the task of integrating 3rd party systems that sit close to Broadworks. Examples of these are Session Border Controllers, IMS networks and call recording platforms or perhaps internal environments such as real-time or offline charging systems, data warehouses and other entities in a Service Provider network.
For third party integrations APIO offers 2 different integration strategies:
1) Webhooks: inform a third party application about any change that happens through APIO. Prefect for loose coupling of both environments.
2) Our workflow engine: allows you to define new API endpoints and overwrite existing endpoints through our UI. The business logic can be created through our service creation environment. This solution is perfect when you need to do proper rollback management etc.
Webhooks
Webhooks are hot these days. Tools such as IFTT or Zapier fully employ webhooks. If your Slack channels are spammed with useless notification about updates in a document on google drive that’s thanks to webhooks. You want to auto-deploy your application when new code is pushed to your main branch of your code? Think webhooks! Most probably webhooks allow you to automate almost anything, maybe except combing your hair, but for the unfortunate ones amongst us, this might be pointless anyway.
Webhooks are “user-defined HTTP callbacks”. They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. In the case of BroadWorks maybe your application wants to be notified about a user creation, deletion or update? Well, no problem.
Let’s just define that event:
Now just subscribe your webservice to the event:
Your webservice will get notified each time a user is created. If that’s not simple what is?
Workflow engine
When simple is not good enough, you’re ready to take for the next step. Meet our workflow engine. Our workflow engine is a task engine able to orchestrate API calls across platforms. You can overwrite the business logic of existing API’s or just create entirely new APIs.
Where do we start? As an example take this simple “Hello World” response and build your first custom API.
Build your first workflow
Give your workflow a name
Every workflow needs a name to be used as a reference in further operations.
Be polite and say hello
To make our workflow polite we want to make it return “Hello, world” in its body response.
Add a task to set the response:
The task is designed to return our message which needs to be a valid JSON body.
End the workflow
Another cell is added to mark the end of the workflow
Organise the cells
Now that you have created the tasks they can be dragged to wherever is visually convenient. Cells are then linked together to organise transitions from “start” to “end” by using a mouse drag & drop any output* to any input**
* outputs are bullet on the right of the tasks
** inputs are bullets on the left of the tasks
Save your hard work
Now we have a workflow but it’s not exposed or available to anyone to run it.
Create an HTTP endpoint
To configure the HTTP endpoints, go to the “Startup events” page
Then create a new custom route (1) which needs a path (2) and a HTTP method (3) – note the final path to help you share your future endpoint.
Our workflow is expected to return its response in a synchronous manner therefore the tick box is checked (4) and the configuration saved (5).
Bind your workflow
The brand new workflow can now be associated with the new route just created.
You are all set and all users authenticated on the platform can trigger your workflow
Trigger your workflow
The new endpoint can be triggered from any HTTP client and a example is provided here of a call from cURL:
curl -H "Authorization: Bearer <user token>" \
http://<host>/api/v01/custom/hello
And the platform returns:
{"message": "hello, world"}
Follow your trace
Calls can be retrieved in the “custom requests” menu (1) including call details and its execution going to the details page (2).
Conclusion
So that’s it. A taste of what you will find when working with Netaxis. Get in touch for a demo and access our brand new APIO lab when looking for an replacement for Loki in Cisco Broadworks. The drag and drop UI makes it a lot easier to generate new workflows and you will be up and running in double quick time.
Read the rest of our blog posts on the use of APIO as a replacement for the Loki portal in Cisco Broadworks platforms. As usual my partner in crime Bart Coelmont and the Netaxis team have been instrumental in helping me with this blog post.
