How does a module call work under the hood?

1

I have a question regarding how a module call works under the hood if multiple parallel tables are calling the same module.

I had an iteration of an Easymorph project where I had a parent table that was derived into three child tables to isolate a distinct window of time for three separate phases or work tracked on the parent record. The module the job was calling creates a workday calendar for the range of the dates. When the same module was being called, I experienced errors. I also tried putting a dependency on them so each would run one at a time but I would get an error on the final table when it would call the module for some reason.

How is the priority determined when multiple tables have an action to call a module at the same time?

I have instead pivoted to having three separate versions of the module, one dedicated for each phase of work. This has resolved my issue but I feel like I might not be structuring my job optimally because I am copying the module's logic and creating the parameters individually inside each module.

image
image1197×1030 48.2 KB

Has anyone had this kind of workflow before? And if so, how do you structure your calls most efficiently?

Best-

2

When a module (or project) is called, EasyMorph creates a copy (clone) of the called module and runs the copy. This allows running the same module in parallel or independently of other workflows, as every call creates an independent copy and runs it.

However, if the called module modifies a file (or alters some other external resource that doesn't support parallel access), then making several parallel calls to the module can cause an error because two or more modules can try simultaneously accessing the same file (or altering a resource).

So, most probably, the cause of the error you saw lies somewhere else. Can you post a screenshot of the error?