Has anyone found a solution to the fact that LeanIX allows only one provider per interface? In the API world we often encounter the situation where the integration middleware consumes two APIs exposed by two separate systems, aggregates the data, and exposes an experience API for as third system to consume. If I model it as two separate interfaces (Provider to Middleware, Middleware to Consumer) I have no way to "connect" the two and show the end2end; if I model as one interface I can only specify one Provider. has anyone figured it out?
Date
Votes
5 comments
-
Hi Gabriele, no guarantee that this will work (and probably the LeanIX folks will not like me for suggesting this), but you could try to go to the self-service configuration, delete the relation relInterfaceToProviderApplication and to recreate it with m:n cardinality. If you really dare to try this, please:
a) do it in a workspace that you can safely delete in case everything breaks hoplelessly
b) let us know how it went ;-DGood luck
Thomas -
By the way - it goes without saying that you will need to recreate all interface provider relations after doing this.
-
Thank you, Thomas. Yes, I imagine the LeanIX folks won't be too happy, but I have to try something; this is a pretty big gap.
-
Hi Gabrielle,
I understand where you are coming from and we have struggled with the same issue.
I have solved this issue by creating an IT Component of type "API". When we create an interface which uses multiple APIs from the same provider application or multiple APIs from different provider apps even, we just add those APIs as IT Components against the interface fact sheet.
In my experience it allows you to sufficiently model the relationships and dependencies without compromising the LeanIX meta model.
You do have to take a call on which app are you going to add as your Provider app in the interface fact sheet. I have gone for the principle that the data object being interfaced will determine the what the provider app should be. For example, if we are interfacing employees from the HR application but enriching that object with additional data from say Azure AD using Microsoft Graph APIs, then by virtue of the primary data object being exchanged being the employee data object the provider app should be HR instead of AAD.
Hope that helps.
BRgds,
Vishal
-
Thank you, Vishal. I can see how that would be a good option in certain scenarios. For us it's not that easy because we can get the same data entities from multiple sources; as a matter of fact, by nature of the business (which boils down to our clients' need for us to use their standard apps) we actually have to deal with multiple implementation of the same product type. This of it as having to use multiple HR systems because our folks track their time in our system and third party vendors use their own.
After much thinking I believe the only option is actually for us to model the middleware based workflow that performs the orchestration as an application in its own right, with the name indicating which entity comes from which data source. I'm afraid when I try it it's going to get a bit messy, but I'll give it a try and let you guys know if I succeed.
Thanks for taking the time to answer!
Gabe
Please sign in to leave a comment.