The link is under the partner forum only, apparently.  Here are contents below.

Executing, Starting, Queuing DM (Data Management) Sequences from BR on Specific Servers

I had a use case where I needed to run approximately 100 data management steps in a sequence, but I wanted some steps to be launched in parallel with other steps, while other steps needed to be run sequentially or in a specific order.

If you set up a traditional DM sequence with 100 steps, each step has to complete before the next step begins.  In this use case that meant the job would run for 24+ hours and never complete or timeout.  

So I first had to start by using a DM sequence that referred to a custom Finance BR.  Inside the custom Finance BR I then was able to ExecuteDataMgmtSequence (meaning wait before next sequence runs (which will then run on same server as original sequence)), StartDataMgmtSequence (start a sequence (which will then run on same server as original sequence) and then immediately move on to next step in BR) or QueueDataMgmtSequence (start a sequence (using either load balancing or the server specified in the new DM sequence to determine upon which server to run) and immediately move on to next step in BR).

The next issue I faced was with load balancing these 100 steps/sequences across the customers 6 (CON) servers.  IF I left all the DM sequences blank in the server setting:

What I found was that, using either ExecuteDataMgmtSequence or StartDataMgmtSequence, that all 100 steps were launched and running on the same server.  This meant that one server got overloaded and the DM sequence still timed out.  Effectively the one server spiked while the remaining servers sat idle.

What I wanted to happen was that approximately 10 of the sequences, that each needed to run sequentially, could be queued up all on the same server, since only one of these 10 sequences would ever run at a given time.

But then as each of those 10 sequences completed, I then wanted to launch 10 additional sequences which themselves could be split across the remaining 5 servers and run in parallel.

What I found is that if I used the command .StartDataMgmtSequence in the custom BR for these 10 additional sequences, they all ended up on the same server as the original 10 sequences that need to run in parallel.  Effectively this overloaded one server until the full set of 100 steps never completed.  The original problem I had faced all along.

The solution was to do the following:

• Launch the original DM sequence that called a Custom Finance BR on CON1 server
  • This was necessary so that I could then sequence the steps via the BR and not in the DM sequence itself

• Launch the 10 sequences that each needed to run sequentially using the ExecuteDataMgmtSequence command in the Custom Finance BR. 
  • These also then launched on CON1, but sequentially since I used the "Execute" instead of "Start" or "Queue"

• Once each of the 10 sequences above completed, I then I launched the 10 additional sequences using QueueDataMgmtSequence
  • I split these 10 sequences up with 2 on each server:  CON2, CON3, CON4, CON5, CON6
  • In the DM job of these additional sequences I specifically called out the server upon which they should run (but you could leave this blank and let OS load balance too)
  • By doing this in combination with "Queue" the jobs got load balanced across the remaining 5 servers
  • This also launched all 10 sequences at once since it was not an "Execute" but "Queue"

The end result was that the ~ 100 steps completed end-to-end in under 10 hours vs running for 24+ hours and eventually timing out.

So using both a custom BR in combination with various DM sequences (all which called out 1 of 6 CON servers) plus using "Execute" and "Queue" commands (vs "Start") in the BR I was able to get 100 steps to launch, some sequentially and some in parallel, as needed for this job to complete correctly.

This is a DM sequence that is run periodically or rarely to reconsolidate all historical scenarios and years for potential rule changes.  It is not run often, but when it does run it needed to be able to complete without timing out.