We would like on interfaces to have a better technical understanding of its set up. In that regards, we are wondering on how to document integration protocol and file format.
Examples of integration protocol: SFTP, REST API, TLS, Manual…
Examples of file format: CSV, JSON, XML, TXT…
We are considering 2 options:
Create a Multi Select attribute on the Integration factsheet
Create these integration protocol or file format as IT component and associate them to integrations.
Any other options?
I will be happy to hear the feedback of people having the same question and that implemented something in their workspace.
Thank you,
Kind regards,
Page 1 / 1
Hi @simonsztabholz , We don’t register all protocols and file formats of our interfaces in leanIX. However, we partially cover the same kind of needs using IT Components. In other words, we want to know if, beside the providing and consuming applications, other technical components are needed by the interface.
Here are some examples of our IT Components:
SFTP Server
Seeburger (EDI tool)
iPaaS (our Azure Integration Platform as a Service)
…
Best regards Didier
We created 4 Subtypes: API ESB (Enterprise Service Bus) FTP CSV
That helps us to group them together easily. We don't need the formats but if we would, I will create a new field with a Singel Select under the Data and Technology.
Regards
Roald
We have a field on the interface factsheet and also link the type to an IT component. The interface factsheet has a data object relationship so we “govern” the security and data privacy risk using that relationship. the data classification drives the level of encryption required etc. the IT component layer links to our cmdb, where the detailed information is stored, we use the resource tab in the factsheets to manage that link. as we are multinational we have multiple sftp servers etc. it is useful to have the field on the interface factsheets as it helps grouping when a change is required csv format or for sustainability reasons. We also created a subtype for APIs as we develop our own systems and the APIs can be grouped under a “platform”. Also as cloud migration continues it helps to see where there are other rationalisation opportunities.
Must data be encrypted in transit and at rest? secure by definition. Subject to EU Data Privacy laws? Commercially sensitive? visibility of hosting locations inside/outside EU, subject to Safe Harbour regulation?
which paths it travels through?
event to API based on payload size?
Hello @simonsztabholz,
we have many interfaces using a middleware in between. We model this middleware as a component linked with the interface. Therefore we added Provider and client technology showing what is used:
e.g. we have an interface using Boomi as a middleware. J.D. Edwards ERP sends Item Prices to Salesforce. On JDE - side a SOAP technology is used to send date to Boomi and on SFDC side ODATA is used to get the price from Boomi in. We intentionally did not use Mulitselection Lists, because it is less concrete.
Best regards, Carsten
Hello @simonsztabholz ,
we do nearly the same as Carsten, but more focus on the Data Format (ANSI X.12, Avro, CSV, EDIFACT, FIX, Flatbuffers, HIPAA 837, IDoc, JSON, MT/MX, ORC, Parquet, PDF, Protobuf, Structerd Data, TRADACOMS, VDA, XBRL, XLS/XLSX, XML, YAML), also enriched with Criticality and Cloud Ready. Its in the interface stored in the category “Data and Technology” and there in the block “Properties”.
And also in this category in the block “IT Components” we put the connection method (=protocoll, list see below) and in a extra field the “Credentials”.
1. API Communication (Web Services)
REST (Representational State Transfer) – HTTP-based API communication using JSON or XML.
SOAP (Simple Object Access Protocol) – XML-based protocol, often used in enterprise systems.
GraphQL – Flexible API query protocol optimized for efficient data retrieval.