Hi,
I use integration API and processor to synchronize external systems with LeanIX, especially the inboundFactSheet processor type. The default behavior of this processor is to identify if the factsheet already exist (usage of the externalId) and update it or create it if it doesn’t exist.
But I don’t know if it’s possible to update it only and not to create it if it doesn’t exist?
Thanks for your help.
Olivier C.
Best answer by Thomas Schreiner
I’m not sure if there are any JUEL tricks that allow to check if the identification succeeded or not, but I have another workaround that you could try: You could create a custom role that only has the permissions to update a fact sheet, but not to create it, and assign that role to the technical user that calls the integration API. I’m not sure if this works or not, but it’s worth a try :-)
Maybe somebody from LeanIX has a cleaner solution than this?
+3Hi Olivier,
The inboundFactSheet processor will automatically create a fact sheet if it cannot be matched using the configured identifier.
Can you influence the logic how the LDIF is created? If so, you could already check during LDIF creation if the fact sheet already exists, and ignore all entries that are not present in LeanIX.
Hi Thomas,
Thanks for your reply.
In my use case, the only way to filter them is to request LeanIX before to retrieve the list of factsheets already existing and as you said adapt the LDIF. But it will be easier if it is possible to configure the processor to authorize only the update and not the creation of a factsheet.
So I understand it is not (yet ? 😉 ) possible?
+3I’m not sure if there are any JUEL tricks that allow to check if the identification succeeded or not, but I have another workaround that you could try: You could create a custom role that only has the permissions to update a fact sheet, but not to create it, and assign that role to the technical user that calls the integration API. I’m not sure if this works or not, but it’s worth a try :-)
Maybe somebody from LeanIX has a cleaner solution than this?
For sure it could be a solution, not a clean one but easy to implement 😅. I will definitively try it!
Thanks for this idea 👍
Great, I test it, and I confirm it is working 💪, but don’t look at the multiple warning in the processor log….😅
+3Awesome, happy to hear! Should you ever come across a cleaner solution than this, please post it here 😊
Hi Olivier,
you could filter processor execution based on current fact sheet content by using the onRead filter. There is an example in the documentation. I just tested it, works fine for me.
The documentation says “The processor can be configured to only execute if a Fact sheet already exists or if the Fact sheet has defined values in some fields.” This should be exactly what you want.
Manfred J.
+1"filter": {
"onRead": "${lx.factsheet.id != null}",
"advanced":"${true}"
}onRead here can be included in addition to the advanced filter that you are applying. Applying onRead filter will mean that you also define the attributes in the read section. https://docs-eam.leanix.net/reference/advanced#example-4
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.