Process instance is running around 3 ro 4 minutes after process is completed in wMS

Hi Guys,

we are seeing that when process model is completed successfully in wMS with status complete process instace is still actvie for 3 to 4 minutes. is the server need roundabout 3 minutes to complete the process? or is it normal ? do we have any setting to keep the process model active for 3 to minute after process completed …

If you have have any idea please suggest me.

Thanks in advance …

Thanks
Miki

How do you see that “process model is completed” and “process instace is still actvie”?

Hi Fml2 Thanks for the reply

in Process model we are waiting for reply(ack) document once reply document is subscribe it move to complete step and complete the Process model . we can see in wMS.

But if we are receiving same reply(ack) document again with in 2 minute of Process model is completed its showing error

  • Correlation ID joins to a process instance that is no longer running

but after 4 and 5 minutes if we will received the same reply (ack) document again its showing different error
-Exception → 0 com.wm.app.prt.ProcessException: [PRT.0101.9206] Intermediate Receive Step S66 of model PriceProcess/PriceProcess version 1 does not correlate to existing Process ID .

I am not sure why two different error when we post the same ack document with in 2 minute of Process model completion we are getting “- Correlation ID joins to a process instance that is no longer running” error and after 4 minute if we will post the same reply document again we are getting --Exception → 0 com.wm.app.prt.ProcessException: [PRT.0101.9206] Intermediate Receive Step S66 of model PriceProcess/PriceProcess version 1 does not correlate to existing Process ID .

Hi Miki,

why are you trying to ack the process several times?

The first error means, that the instance has been completed already but is still in the list of recent instances.

The second error means, that the instance is no longer in the list of recent instances and therefore no instance can be identified to join to.

As Audit Logging is usually asynchronous, it might take some seconds until all data is persisted in the real database. Meanwhile it is buffered in a Derby Database using LigthWeightQueue mechanism (SCG_LWQ fetaure).

Regards,
Holger

Hi Thomsen,

Thanks for the reply,

Can we check the instance has been completed already but is still in the list of recent instances anywhere?
do we have any setting where we can define the value till when instance should be in the list of recent instances.

why are you trying to ack the process several times?
we are receiving multiple reply from target.

Thanks
Miki

Hi Miki,

are the addiitional acks required for further processing or just send “accidentally”?.

In the first case you will to rework your process design, in the second you can just go ahead with the current behaviour and ignore the messages.

Regards,
Holger

Hi Holger,

Thanks for the reply,

issue is with the target they are sending multiple reply in some case.

But I want to know anyway we can check the instance is still in the list of recent instances ?
any stetting where we define the time till when instance should be in the list of recent instances .

Thanks
Miki

This is because there is a cleaning job working in background which removes correlation entries for completed instances. It makes sweeps every N minutes (5? I’m not sure).

Hence, if you send the doc shortly after the instance is completed you get the first error message. Two minutes later the job has deleted the correlation entry. Hence the PRT can’t find any instance for that correlation and you get the second error message. But the end effect is the same: the document you send can’t “dock” to an active process instance.

The instance is of course still in the list of the “recent instances”, otherwise how would the monitor find and display it?

1 Like

Hi fml,

thanks for clarifying this.

The Interval for the correlation sweeper scheduler is configurable in the WmPRT config screen.

Regards,
Holger