Question

WaDaCo Process MOVE_PART timing out

  • 13 March 2023
  • 7 replies
  • 320 views
C
Rank
Userlevel 3
Badge +6

Hey IFS Community!

We're having some issues with a configured WaDaCo flow: MOVE_PART. The flow is supposed to move all the part records from one location to another at once, but it keeps timing out after just one minute on the scanner. Weirdly, it was working fine before, but after last week, it suddenly stopped working. We're currently on APP10 UPD14. The records on the from location is about 65 part lines with a connected WDR number. It hasn't been increased. We have used the flow for half a year without any issues - until now. Also, we haven’t had any deliveries from IFS. I recall it took about 1 minute and 30 seconds to execute, but I’m not 100% sure.

The scanner's giving us the error message 'Unexpected http status code: 500 ERROR_CLOUD_UNKNOWN_EXCEPTION: The operation has timed out'. 

I’m wondering if anyone else has had the same issue, and if it's possible to increase the scanner’s time out time.

Also, if you've got any ideas on how to optimize the MOVE_PART flow so it works better, that'd be super helpful. The flow need to move all records from one location to another at once.

Check out the pics I attached to see how the MOVE_PART flow is configured.

 

Cheers!

7 replies

D
Rank
Userlevel 6
Badge +16

Hi @Christian Cordius 

Hmm your have configured it in way I don’t think I have seen before. You are not using internal loop from what I can see, so each session is executed separately I guess. So when does this time out happen, is it during execution or is it between some items?

You can see some hints if you check the Data Collection Session client but it will only show performance issues between certain items, if the execution takes time it will not be clearly seen there.

Since you have not taken an update for a while you say and it worked previously maybe this is performance issue due to increasing large number of records in certain tables.

2 things I could think of if you are running the background job that will cleanup the wadaco session tables from time to time? It is often customers forget about that and then the increased volume of old records can start slowing down wadaco generally.

Also since this is move part process that access the inventory part in stock data source, it could get bad performance after a while if you are not running the cleanup job for inventory part in stock, that will remove all zero quantity records that exist there.

 

C
Rank
Userlevel 3
Badge +6

Hi Zani, 

I tried with the loop function and it didn’t help. I’ve also tried to execute as background job which didn’t help either.

It correct each session is executed separately in my configured MOVE_PART flow. However, before IFS starting execute the movement, it will first go through all records which will be moved and afterwards IFS makes the movement. I think this is a bug because it should only consider one line in each session. Now IFS tries to execute ‘all’ records and it times out. It not taking one line at a time.

MOVE_PART are using Inventory Part in Stock. However, when I’m starting to look into the from location, i have already narrowed down records, so it is only approximately 65 wadaco will handle. I think this is manageable for the scanner.

We’re already cleaning up the inventory part in stock table for zero quantity records each day with a scheduled job. 

In regards to your other question we’re only cleaning up sessions which is <> Completed. I can see we still have Completed records from 01-10-2020. Total ‘Completed’ sessions in data_capture_session table is 659.269 records. Will you recommend we’re cleaning up in this table for completed sessions?

 

Do you know if it’s possible to increase the time out time on scanners? 

 

Cheers

C
Rank
Userlevel 3
Badge +6

Also, do you have an idea on how to configure the scanner so it’s possible to move all records from one location to another in an efficient way?

Thanks!

D
Rank
Userlevel 6
Badge +16

Hi @Christian Cordius 

I’m a bit confused now, as I remember this process only executes one stock move per session with this configuration so I can’t understand how it would do 65 for one session. Does this process have a customization somehow so it can do multiple stock moves at the same time, since that is not how the core process works as I remember. What you describes is more or how it would have worked if you were using an internal loop, which you are not using apparently.

Plus 65 stock moves would create some transaction history posts also I would guess, that could take some time.

So does this timeout happen when the execution is suppose to happen then, since that was not clear to me here?

Yeah I would recommend to clean up the wadaco session tables with the background job 'Remove Data Capture Sessions' regularly if you have a large number of sessions. Your 659.269 sessions record is like 20-40 times records in the session line table, which is a lot and can affect the performance.

Not sure you can change the timeout much, maybe something can be slightly increased on the Touch Apps Server side, but I’m not an expert on that area.

/Dario

D
Rank
Userlevel 6
Badge +16

Also, do you have an idea on how to configure the scanner so it’s possible to move all records from one location to another in an efficient way?

Thanks!

No not much you can do in the scanner. What you are looking for is to create new or customized process that will do all that in one session. And if that takes a long time to execute the execute in background option could be used to avoid waiting for the execution to finish so it will not cause a timeout in the scanner.

C
Rank
Userlevel 3
Badge +6

Hi Dario,

The flow is configured to execute one stock move per session. However, this is not the case. When I use the configured MOVE_PART flow on the scanner, for some reason, it seems like the flow is going through all lines and executing all of them at once. A session is created per stock move after the execution is confirmed, but before the execution of the flow happens, the flow goes through all lines on the location and makes the movements afterward. I find it quite hard to describe, so I have attached examples of two scenarios where it works and where it is not working. The timeout occurs when executing the configured flow on a location with more than 40 records. Please see the attached zip file, and remember to view the files in the correct order, 1, 2, 3, and so on (remember it is two scenaios, so you need to consider works and not works). If this does not make sense, please let me know.

I have cleaned up the session table, but it did not work. The table in our test environment only contains 33 records. The attached example is from our test environment after the clean up.

 

I have tried different setups/configurations for MOVE_PART, but unfortunately, nothing works. For example, I have tried looping all parts in one session, executing as a background job, etc.

Can you advise on how I should configure the MOVE_PART flow so that it is possible to move all records on a location to a new location in one flow? I do not know if this is something you can do, but maybe we can have a call on Teams?

1 Attachment
D
Rank
Userlevel 6
Badge +16

Hi @Christian Cordius

I think you might have a customization done in this process that makes it try and do all these moves in one step so thats why it feels strange to me that it works so, since that is not the core functionality for this process.
I noticed you have customized data item C_NEW_WDR_NO so I'm guessing there might have been other customizations to this process also.

I think you have that customization just because you wanted to have this functionality you describe: "A session is created per stock move after the execution is confirmed, but before the execution of the flow happens, the flow goes through all lines on the location and makes the movements afterward." 

So my first guess its this customization that now takes long time so it timeouts due to that. So who ever did this customization might have to look into that code and see if any thing can be done to increase the performance so it will not timeout, or the alternative is to run this in the background but then the user will not get any direct feedback if the move went well or not.

Something must have been changed in this process since scanning only to and from location should normally never create x number of sessions either unless it something with this configuration that I have never seen before. Like maybe the auto-pick setting on the some of the stock keys can automate the system to do it like you describe, but I have never seen or heard anyone setup the process in that way, in theory maybe it could work, I cant say for sure. It feels like you are stretching the system in way I don't think we thought of or intended. But in that case the main problem is that all that still takes a long time doing this without any user interaction, if there was some user interaction for each session this would not happen. 
One way could be to enable the Confirm Execution checkbox on the general tab but then it might annoying to having to confirm all these x number of sessions, but at least it should not timeout then. 
Another thing could maybe be to turn off all Use Automatic Values for those data items (like PART_NO, ENG_CHG_LEVEL, WAIV_DEV_REJ_NO and CONFIGURATION_ID) you have setup as Auto-Pick in the LOV, to stop the system from trying run the automatic value code since that could be slow in some occurrences and unnecessary in this case if the value is fetched by the auto-pick LOV (since it is always called before the LOV code), that might increase performance a bit if it actually is running and creating x number of session due to this special configuration.
Or in worse case you might need a customization like I mentioned earlier that will do all the moves in one single session instead of x number sessions,  that needs to be run in the background if it will cause a timeout to the client if it takes too long time.

 

 

Reply


Terms & ConditionsCookie settings