API Integrations
Polonious provides an extensive set of REST APIs to query data and create various entities in the system.
One of the core strengths of our case management system is that is is very flexible and adaptable to differing business needs.
Our REST APIs reflect this, and our future road map for them will take this a step further.
Create Case flexibility
Create Case is our most used API, it’s the gateway to initiating action inside Polonious for some trigger like Fraud detection or a referral from Claims.
This API has its own web interface to enable pretty much anything to be used as data to create a case. The interface allows a user to configure a mapping of inbound fields by uploading an example JSON. This JSON needs to be ‘flat’. ie the data has to be a single level of attributes. This actually covers off on 95% of our integration needs with the backup of additional REST services for the more complex cases where, for example, variable numbers of participants are involved.
Outbound REST Call flexibility
Our Polonious customers are now very familiar with the ability of Polonious to automate outbound integration tasks.
To achieve this, we often use a key transaction point in our application, the Case Note (or action, diary, update as some of our customers call it).
This means, you may want this integration to only happen at case inception, or at case review or case update, or possibly only at case close stages. Possibly at all of the above. Our Polonious Persons can configure this for you. No Polonious IT resources are usually needed.
How this works is fairly straight forward. For any type of case note, you can setup a REST call that can locate, collate and send any case data from that case (I mean any case data, including other diary entries, person, vehicle, company data from the case, any metrics gathered on the case either singular or as totals).
Our Polonious Configurers understand how to access the deep case data and can share many examples of how to use it with your team. The technique is pretty easy to use if you’ve used a templating/programming language before. This generally needs no input from our internal IT team reducing costs and speeding the process.
For complex integrations we use an adaptor
In many of the more complex needs, systems talk different protocols and need ‘cleansing’, selection or verification of data on the way to their penultimate system. To do this, we use microservice adaptors. These can be written by our teams at Polonious or your own IT teams. They can be written in any language your team is comfortable with. We have customers who have created these adaptors in languages other than Java such as python, c# and used them to
talk to/from all sorts of different protocols like webservices, sftp,and the like. 
The end point for this payload can be another system you’ve designed that talks any of the major security protocols or it can be an ‘adaptor’ web server written in any language (we prefer Java but some customers use node.js, .net, python and others. That adaptor can then forward the data (possibly after adapting it) to your internal applications in a way they understand.
Using an adaptor provides the additional benefit that the integration source code can be maintained separately from the core systems at either end. This makes updating and writing automated tests for it far easier. It also makes it much easier to understand to a new developer which improves maintainability and change cost. Due to the versioned APIs we use, this adaptor will not require regular updates to keep up with API changes.
Finally, an adaptor is just that – it can adapt more easily to internal security changes and other needs. We can easily send you more information (just by changing the payload with a quick call to our Polonious Persons. The rest is easy (excuse the pun), just a small change to the adaptor, re-run any tests, and you’ve updated your security or business requirements. You can change underlying systems with reduced pressures of dependencies as those dependencies are easy to maintain separately from the core systems.
If you are a Polonious client, we have a number of great examples we can share with you of this from our Spring Boot collection. This makes it really easy to stand up a new adaptor as and when needed.
