Skip to main content

Hello,

 

We are facing a huge issue, in our test and config environments, we cannot inspect workflows anymore, even if they only have a simple projection call in it. When inspecting, we just get the “loading” popup that never goes away.

 

This is on 23R1 and so far, it seems like no one else has been experiencing this other than us.

 

What could be causing this? We’ve refreshed the caches in hopes of resolving this issue but so far nothing has been working.

 

Any and all insight would be very much appreciated.

 

Thanks,
Bryan

Is there a possibility can you share screenshots or a sample workflow to get a better idea on the issue?

Hi @kamnlk 

I’m attaching a screenshot of the issue. This is a very simple workflow, a read and an update projection call for customerorderhandling. It reads an order to verify the order exists, and then attempts to update a field in it, but both calls require an orderno input parameter. This should error out instantly since I dont define an orderno variable in my inspect variables, but it stays on this loading… page forever until it times out. This happens with all workflows, even if its a start → end workflow that doesnt do anything except immediately end.

 

We have a case in with IFS about this and will update the community post with any new information they provide.

 

Thanks,
Bryan

Hi, any news with this issue?

We found that if we run inspect in BPA which has a collection of a lot of data an error occurs: "Bpmn_Debug_Activity_Log_API.Update_Activity_Log_Variables(? , ? , ?);\n END;\n\n The table has been truncated because the number of events for the request exceeded the allowed limit." and the Oracle session will lock tables such as IFSCAMSYS.ACT_GE_PROPERTY. Therefore, inspect then does not work on any BPA. You need to kill this session to make inspect start working properly again.

We had to request IFS restart our service pods and containers for workflows, which resolved the issue @InfJurajC 

Hi ​@bdoucette 

Can you clarify this, what are containers for workflows?

Hi ​@Viitati,

I’m referring to the Kubernetes pods that act as containers. If you are cloud hosted by IFS and are experiencing this same issue, you should be able to submit a pod restart and specify this should be done for the pods that handle the workflow processing.

If you are not hosted by IFS, but hosted on prem, this would require identifying which one is associated to workflow processing. We haven’t had to do that so I can’t help you there but I’m sure there is documentation that could help with this if you looked for it.

Best,
Bryan

Reply


Terms & ConditionsCookie settings