Forum Stats

  • 3,838,726 Users
  • 2,262,395 Discussions
  • 7,900,741 Comments

Discussions

Steps to migration Oracle Workflow - 2.6.4.0.0 to BPEL 12.2.x

3676032
3676032 Member Posts: 2
edited Feb 26, 2020 10:34AM in Business Process Management Suite

I am upgrading the software stack for my application and will be moving from Oracle Workflow - 2.6.4.0.0 to BPEL 12.2.1.1.0.

I have already redesigned my flow in BPEL and they work fine in the new environment.

Next -- Upon searching for migration options for data associated earlier workflows, the search results on the support website were vague.

In fact i have an Oracle rep tell me (off the record) that no migration scripts are available between the 2 entities.

However i just wanted to confirm the same.

In understand that closing existing workflow processes is the ideal way ahead and of the many flows present in the system I have persuaded the client to oblige on all but one.

Any help associated with pointing in the right direction may be a great help.

Also wanted to understand if an intermediary migration can be done say (for example) from Oracle Workflow to Warehouse Builder 11g and then ahead.

Thanking everyone in anticipation for the time you spend on this post.

Regards,

Zoheb Khan

Tagged:

Answers

  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited Apr 7, 2018 7:09AM

    Hi,

    Do I understand that you want to migrate running workflow instances to BPEL?

    Simple and short answer: you can't and I'd say you should not invest time and money in it.

    There are three approaches:

    • Make sure that new instances are started in BPEL and let running instances finish in OWF.
    • Refactor your BPEL processes to enable them to be started at points reflecting the state they're in in OWF. Then for each running OWF instance, start a BPEL instance at the  particular entry point.
    • Start a BPEL instance for every OWF instance, and using API's work them through the process to get each of them to the proper state in BPEL.

    I'd once did something like the third bullet when migrating an application to Oracle Workflow. But I would not recommend that with BPEL.

    In an OWF application we were used to use the wf_item_activity_instances table as an audit trail. Sometimes customers want to do the same with BPEL and/or BPM, and thus define a retention policy on the dehydration store. But you really should not. Functional auditing should be done outside of the process manager in custom tables. Only have a retention period on process instances for possible fault investigation. Besides that, purge completed instances as soon as possible. I believe it is 2 weeks per default, which seems reasonable to me.

    And by the way, back in around 2004 the statement of direction of Workflow stated that BPEL is the envisioned successor of Workflow. But with the introduction of BPM11g PS6, there is an import of Oracle Workflow processes into the BPM designer. I'd say that BPMN is the better alternative for migrating OWF.

    Oh, and an extra treat: I did a migration of Workflow to BPEL once. And we had several constructs in OWF that it looped to check a certain state in a table. An external event would switch the status in the table to get the workflow proceeding. We did a 1:1 upgrade for that. And how I pitied that! Those constructs should be redesigned using an AQ queue and a polling AQ adapter. Then with the change of status in the database, a correlating message on the queue should be put. Then the AQ adapter can poll for that.  When modelling that in BPEL with a wait for a minute or even 10 minutes and having it wait for weeks, the flow trace would grow excessively. Resulting in a very slow EM and other system components.

    Please do yourself a favor and be critical on OWF constructs that are fine in OWF, but really are anti-patterns in BPEL.

    Kind regards,
    Martien

  • 3676032
    3676032 Member Posts: 2
    edited Apr 9, 2018 1:34AM

    Hello Martien,

    Thank you for the valuable inputs, I am hoping for sense to prevail with my superiors when push comes to shove.

    Of the 3 approaches you mentioned, I have already begun work in that direction.

    My best possible workaround for my client is that all pending OWF instances shall be brought to a same/ similar progress in a new BPEL flow (by using the powers of an admin user to override dependencies) and let the end user continue on from there on.

    Let's see how that goes.

    Irrespective, thank you for the correct and to the point references. The response was impeccable in all aspects.

This discussion has been closed.