Hi

I am planning to move work flow (process) from one server to another server while process is in run time and process should run from where it was available in old server. I would like to know what would be pro and cons. I would like to know what all things I have to take care.

When I am trying to do this… process instance id is dying and not able to find the same in new service instance.

Your ideas would be appreciated.

Thanks,
Tarun

@Tarun,

IMO, this is not possible as every instance of process gets a universally unique instanceid which is weaved around different tables of PRT and process documents.

Theoretically it is possible if you able to replicate the state of PRT DB and documents.

What I learnt from migration project is, wait till all your process instances are completed before you phase out the server instance.

Like to hear from other expert on this.

Thanks,
Rankesh

I believe this is possible but tricky. I agree with Rankesh that the best way would be to complete all running process instances and then move to the new server. But may not always be possible due to the way the processes are designed.

But, it should be possible if you clone your DB and the new server is pointing to that db. We have recently moved our servers and the requirement was that the old processes should resume.

But if this is a requirement, I would suggest contacting SAG.

How did yoou move it in the first instance though?

Thanks and REgards,
Ninad Patil

Hi All,

We can get this done by keeping the processes available in both the servers.

first write a service to check whether the process instance is already existing in old server or not.

if it is in old server bpm tables…then continue with old instance till it is completed

if it is not available in old server bpm table try to connect it to the new server using a bridging service (webservice) and let a new fresh /existing process in new server, if this has been done until all the process instances are completed in old server then we shut down the old server and route all of them to the new server.

first test in non production environment, Iam also testing it will let you know the results soon.

Regards
Sandeep

Hello Sandeep,

I would like to know have you created any bridge service like this ? If yes , please share the details.

This migration of “in flight” processes is possible and there are several options depending how much downtime you can afford.
If needed there can be also a “no downtime” migration done - for sure with extra effort. if you have “long running processes” or archiving needs definitely worth it.

It would be helpful if you describe your boundaries a bit in more detail.

Till then putting a tools name into the ring: PMM - Process Merge Migrator. It allows you to merge two instances and make sure the mentioned unique process keys do not run into conflict during that merge. This way you can start a new instance while the old one still continue and then you define yourself the point in time to shutdown the old one and merge the processes with the new one. (ideally first upgrade the old one in place to have them at the same version when merging – e.g. both 9.12 or both 10.3).
If you want to license the PMM tool please talk to your license sales or professional services contacts.

Dear holm,

Thank you for your reply.

We have long running processes and need to migrate from (9.9) to 10.3. I am looking for best approch to migrate this and avoid to keep old infrastructure up and running.

Could you please elaborate more on PPM and share documents if you have.

The main point here is if you can deal with an downtime or not (or at least minimize it).
When you can have a downtime this is strait forward as described in the migration guides.
The running processes will after migration keep flowing in the new systems like nothing was happen.

The challenge when you have processes who are affected by downtime is to keep the old system running while setup the new one, on day x switch for new inbound traffic to the new one, then upgrade the old separately and finally merge (manually or automated).
In that approach there no general downtime, but for the old processes still a little “pausing” while they are upgraded and merged.
Anyway it avoids a general system outage.

For a detailed planning of such migration you should engage with your Software AG Professional Services contacts. They can also help you on PMM for 10.3.

Hi,

You can use the procedure for migrating process engines, which basically migrates all data from the original server to the new server (which is installed side-by-side).

You should then set the inbound and outbound services and documents (triggers) so that only the instances you want are continued on the new server.

This is a rather complex operation and you must be sure to discover all the interfaces affecting the processes.

Good luck.