Set starting Flow Run Id / Execution ID

Hello.

We want to install a fresh version of Operations Orchestration Central.

We are using another System with a database in which we store the Flow Run IDs of Flow Runs to have a unique key. If the new Central starts with Flow Run Ids from the default start number we will get duplicate entries in the other system which will cause a lot of havoc.

Therefore we are looking for a way to set the starting Flow Run Id aka Execution ID in the DB in Central to a specific number. Is there a "official" configuration or a dirty hack to do this?

Thanks for your help in advance.

Kind Regards

  -- Sascha

  • Hi Sascha,

     

    There isn't an official way to set the starting Run ID. You can create an Idea to add such feature in future release on the Idea Exchange portal: /it_ops_mgt/sws-oo/i/OO_Idea_Exchange

    I hope this information finds you well. 

  • Hello, Carlos.

    Thanks for your answer.

    I will create an idea.

    But I'm surprised that I'm the first person, which encountered this issue.

    Is there maybe an "inofficial" way to do this? I guess that somewhere should the seed of the Execution ID or the last used Execution ID be stored. Or is this a identity column in some table? Any information is appreciated.

    Thanks in advance.

    Cheers

      -- Sascha

  • Why don't you concatenate the originsystem (source hostname) with the run id? We do this and have no issue

  • Suggested Answer

    Hi Sascha,

    The execution id for new executions as well as any other IDs  that have to be uniquely generated are generated from a controlled range of values which central manages internally. One of the reasons why this occurs is specifically to avoid ID collision in periods of high activity especially when multiple Central nodes are clustered together.

    Tampering with this system may have undesired side effects in other parts of the application as such the "hack" you are looking for is not going to be a good idea.

    Now regarding your system of storing the execution ids if the old central and the new central are going to be running in parallel even if you manage to get the new system to start from the same range as the old one, eventually as part of normal executions you will get collisions in your primary key naturally.

    To avoid any such issues and to avoid doing hacks to OO i would suggest something similar to what Sergio proposed: in the database where you store the execution ids add another column to the table which identifies the central environment from which the execution id originates and modify the primary key to be on the 2 columns (execution_id, origin) so that you keep the benefits of having the primary key and the unique factor relates to pairs of execution_id:origin.

    Hope this helps,

    Vlad