sequential execution of queued dataport runs

[djdgtls]

Which ways are there to execute dataports in a sequential order? Sometimes we want to explicitly run a sequence of dataports, for example to create an object first and afterwards create a new relation to this object in other objects. We know it's possible with defining a dependent dataport in the result callback function of the dataport that should run first. But is there another way to explicitly tell a dataport run to wait until another dataport run has finished?

[BlackbitDevs]

There are 2 ways:

1. Dataport chaining as you described with executing dependent dataports so that you only have to start the first one which at the end (or even when processing a single raw data item) can call another dataport (and also process its response document if necessary).

2. Concerning

   But is there another way to explicitly tell a dataport run to wait until another dataport run has finished?

   This is conceptually not as simple as it sounds because such a dependency should also work if there are multiple parallel runs of a dataport.

   But let's assume you only have one dataport run at a time. In this case you can use the initialization function. This already offers a callback function template to abort the import if another process of the same dataport is currently running. Of course you can adjust this so that you abort (or better queue current dataport run to be executed later) if currently the dependent dataport is still running. You can develop this lock further by using Symfony Lock or a Pimcore website setting to lock the dependent dataport until the first one is finished.

The most complicated thing here will not be the lock but to re-queue the dataport run which has to wait for the other dataport run to finish. I am wondering if we should introduce a new processing of the return value of the initialization function. Currently there is true for continue and false for abort. But we could introduce another return value for "execute later" (aka re-queueing). Please notify me if this would help you...

But in my opinion dataport chaining and calling dependent dataports from inside callback functions is the way to prefer. Why do you want to use a different approach?