Current State of Development (August 3rd 2018) — the Unibright Connector

As outlined in our blogpost about our strategy on community updates, this blog series shows what we are currently working at. It will give you some insights on specific questions we are dealing with right now and also on our overall progress.

Last time we gave some insights on the Unibright Explorer, this time we will have a closer look at the Unibright Connector.

The connector is the part of our Unibright framework that brings all the IT systems and blockchains together. It is based on our existing (cloud based) integration platform, which is up and running since 2011, serving clients from the banking and production sector.

The Unibright connector consists of different elements:

• An endpoint is the source or destination of an integration process
• A channel is the technical part of a connection between an endpoint and the connector. Unibright offers…
  - SOAP based webservices
  - REST
  - FTP reading (also polling) and writing
  - RFC
  - SAP IDOC
  - Reading/sending data from/via email attachments
  - Reading and writing to Databases
  - Accessing local blockchain nodes (individual channel per blockchain implementation)
• A contract interface is an object representation for a specific target system (represented by an endpoint), for example ORDERS01 IDOC in SAP
• A mapping is an xml-based description on mapping and transforming one contract interface into another, taking into account object specific constraints on datatypes, data lengths, formatting and unit systems

So what does the connector actually do within a blockchain based integration process? Let’s do an example.

Multi Party Approval process, defined in the Workflow Designer

Say, we created a visual definiton of a multi-party-approval, telling that there are different departments who have to give their “OK”, so the next approver can give his feedback. With the Unibright Tools, we can select a dedicated connector configuration (“Smart Adapter”) for each single approver!

• The Design department gives their feedback by mail. So we take “mail” as the incoming channel, “blockchain node access” as the outgoing channel and the mapping contains all information to map the sender email (like jon@company.com) to the value “OK” of a specific smart contract (generated by Unibright tools)
• The QC department clicks on a “OK” button on their own system, which calls a web service in our connector. So here the incoming channel is a webservice, the outgoing channel again is a “blockchain node access”

As we split between definition and implementation, the decision which approver will be represented by which smart adapter can be done AFTER the visual definition of the process.

By the architecture of the Unibright framework, the process specialist who is designing the approval, does not have to care about all this details of webservices, email mappings, and so on, but lets a tech guy decide before publishing the smart contract, using the Unibright Connector — this is (Uni)bright!