...
The essence of what is described here is having Digizuite automation and workflow as the glue which connects your platforms when it makes sense.
We are focusing a lot on reusability and open examples, so if you want to see examples of use then go to
Embedded UI Examples: https://github.com/Digizuite/embedded-ui-examples
API, Postman Collection or Automation Examples: https://github.com/Digizuite/integration-api-examples
| Info |
|---|
The below patterns can be supported but not necessarily with out-of-box capabilities. Some require custom implementation using the SDK whereas others can be taken 80% out of the way using for instance Integration Endpoints or Automation in combination with the SDK or custom code. |
...
Patterns that are very common in the Enterprise Ecosystem would be
Broadcast or one-way Data Exchange (Basic Integration)
A form of integration where (based on some business logic within DAM), data is send to a receiving system. It be very specific business logic that triggers it such as certain metadata fields changing and has a certain value, or it can be all creates, modifications and deletes of assets that must flow to the receiving end. Easily supported by out-of-box Digizuite capabilities such as Automation or Integration Endpoint. Easily extend by the use of your own service or a simple Azure function which is described here on this page.Bi-directional Data Exchange (Enhanced Integration)
It is a combination of the above, but where either certain must be broadcasted but then based on the response something updated in the broadcasting end (Digizuite). Here it could more complicated where certain changes in the receiving system must trigger updates in the Digizuite platform. Here, the question is the amount of data but often Digizuite API or SDK would be a great fit for the data coming in whereas the broadcast elements is as stated in 1.Correlation Data Exchange (Enhanced or Advanced depending on use-cases)
Data from the integrated systems must be correlated in certain ways. An example could be a PIM platform that must not only receive assets but those assets must automatically be linked to a product based on the Product ID on a metadata field on the asset in Digizuite. Here the recommendation is to extend the platform with Azure Functions or your own 3rd party service that is called by Automation or Integration Endpoint.Enhanced UI with an Asset Picker (Basic Integration)
An integration pattern that does not as such move data around is enhancing a 3rd party UI with more capability coming from another system. An asset picker from Digizuite which is being popped on a certain action. When an asset is selected or clicked in the asset picker then at that time it must be integrated into the 3rd party platform (could be adding the assets into a media library, or adding it to an email template for adding it for your product in a PIM as done with our InRiver connector)Combined Data Exchange and UI (Enhanced or Advanced depending on use-cases)
This one combines both data exchange (where assets are moved back and forth) with having UI capability in the 3d party platform as described above. Essentially, you have flow of data that is then further complimented with a UI that allows you handle assets in Digizuite right there when needed. An example is making a crop that is then automatically flowing from Digizuite to the receiving system. It could be updating metadata such as assigning a product ID without leaving your host platform which will then trigger the integration in real time.
To support the above, then a list of mechanisms and tools within the Digizuite platform follows here. It can give you a head start to development and reduce both implementation time, cost and risk in the project.
...