Hi 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?

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?

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….

Awesome, 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.

@Olivier C. : I will recommend as Manfred mentioned above to update the filter section as below in the inboundFactSheet processor.

"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