Using the Unibright Connector to integrate SAP ERP and Microsoft Dynamics 365 via Baseline
Last week, the Baseline Protocol, an OASIS open source initiative, published a demo of multiple companies digitally managing purchase orders and volume discount agreements across disparate systems, as explained in the official press release. Unibright played an essential part in bringing that demo up and running, especially by using our Unibright Connector. This blog post grants some deeper insights on this central component of our Unibright Framework.
The Baseline demo
The procurement use case in the demo highlights how two Enterprise Resource Planning (ERP) systems, Microsoft Dynamics and SAP ERP can maintain consistency with each other by using blockchain technology without exposing information about business activities or relationships to competitors or the public.
Being a founding member of the Baseline Protocol, Unibright played an essential part in bringing that demo up and running, together with Provide and Envision Blockchain. We at Unibright extracted the domain model from our Unibright Connector, set up a connection proxy to the Provide/Baseline stack and integrated SAP.
You can find a video walkthrough of the demo here:
The Beauty of Integration
One important thing to remember about integration projects is that the less you realise you are using the integration, the more successful it is.
In the presented demo, a Request / Proposal / Purchase Order process has been baselined while keeping the user flow for the participants just as it has been before: They still use their respective ERP frontends (in this case SAP ERP and Microsoft Dynamics D365) and the proper integration ensured the communication using the Ethereum Mainnet as the “magic bus”.
To make an integration that smooth, the integration tools have to be supportive and user friendly. Let’s take a look at setting up an integration case with the Unibright Connector.
Unibright Connector Walkthrough
The Unibright Connector supports the complete lifecycle of an integration case, incl. setup, mapping, publishing and monitoring.
Step 1: Setting up a Connection Pipeline
The Unibright Connector lets you define “Connection Pipelines”. A “Connection Pipeline” defines a message flow from integration endpoint to integration endpoint. It defines the technical channels used to transport the message, the structure of the messages themselves and the mapping between different message types.
Step 2: Defining the mapping
The mapping specifies how an incoming document should be mapped (or “transformed”) into the target document. Document Types are for example Unibright Template Models, standards like EDIFACT, quasi-standards like SAP IDocs or simple DataTransferObjects from a specific service interface.
In the Unibright Connector, Mappings can be maintained visually or by mapping code in C#, using functions.
Step 3: Publishing
In a last step, the connection pipeline needs to be published to a runtime environment. The publishing includes:
- The definition of where the mapping should be hosted
- The definition of the endpoint parameters (like target addresses, connection strings and parameters)
- The actual publishing of the code including the mapping
The publishing part can be automated. For example, this has been done in the Unibright Demo for MultiPartyApproval use cases: Each time we have a mapping from an Email to a Blockchain transaction, there is a small piece of mapping code that looks like this and can be published (e.g.) as an Azure function:
Step 4: Monitoring
To monitor ongoing integration messages, occurring errors or status changes, there is an included monitoring dashboard in the Unibright Connector. This dashboard uses an API as well, and this API can be integrated into existing monitoring software like the Unibright Explorer, it can act as standalone or in a web environment.
The role of the Unibright Connector in the Baseline demo
There are situations, where you start integration projects, and have different development teams waiting to “connect their stack”, but you do not know the target object yet and target channel yet. One reason may be, that the system you want to integrate is currently still developed, not up and running yet or does not have standardised models.
This was the case during the baseline demo. As an integrator you have to be aware of these situations, and it is important to provide a development environment, in which all participants (e.g. distributed software teams) can continue working and are not blocking each other. One solution to this can be a proxy. A proxy is a intermediate layer that you establish in an integration process. The proxy only consists of simple domain models descriptions and basic operations like “Get List of Objects”, “Get Specific Object” or “Create new Specific object”.
The Unibright connector can automatically create these proxies, and this is exactly what we did in the Baseline demo: As the Baseline Protocol itself is still in its bootstrapping phase, it was not possible to just use a perfectly working “Baseline” endpoint, and feeding it with perfectly designed and standardised data. So we created a Unibright Model for the procurement use case we wanted to show, and designed basic DTOs (“Data Transfer Objects”) for all the object types involved, like RequestForProposals, Proposals, PurchaseOrders and so on.
We also generated a service interface for all these DTOs automatically, and an authentication service as well.
This gave the whole distributed team the possibility to keep on working and not being blocked from each other:
- Based on that, we were able to configure our Unibright Connector to integrate and map the SAP models with that proxy automatically
- The other teams used this proxy to connect for example D365 objects to that proxy
- The team around provide.services were able to work on the actual Baseline architecture and connection
- In the end, we manually “wired” the proxy to the Baseline stack from Provide and had a complete integration
In a later and more mature stage of the project, the basic DTOs could be replaced by standards from X12 or Edifact, for example.
Unibright’s contribution to the open source idea
As baseline is an open source project, we decided to contribute the automatically generated proxy incl. the custom coded Baseline connection (via the Provide stack) to the open source community. This also includes the fact that for using the proxy, you do not need any UBT, so everybody can use the proxy for free to keep baseline growing.
You can find the code in the official github repo: https://github.com/ethereum-oasis/baseline/blob/master/examples/erp-connector-proxy/README.md
In the scenario above, we used the Connector for proxy generation and for connection of SAP to the proxy. Both these tasks require UBT! We covered them from the 3 million UBT that has been locked in by the Unibright Team for EEA/Baseline by the end of 2019. When locking them in, we exactly had in mind to support the first showcases and provide workshops around baseline for potential future customers. This is a great effort and we want to thank all of our Unibright team members that have been involved here.
All other parties using our proxy had to connect to it by custom coding, which works perfectly well, if you have a dedicated development staff that is able to write custom code. If it is about scaling big time, and offering connection of the same use case 1000 times a day, our automated solution — the Unibright Connector — is the perfect tool to keep a business focused on its daily work and abstracting from technical details when integrating with the Baseline Protocol.
Unibright is a team of blockchain specialists, architects, developers and consultants with 20+ years of experience in business processes and integration. Unibright turns ideas into businesses, and improves processes with the help of blockchain technology.