Migration

You can migrate orders from TIBCO® Fulfillment Order Management 4.0.2 HF-12 (FOM 4.0.2 HF-12), TIBCO® Order Management - Long Running 5.0.0 HF-5, and TIBCO® Order Management 5.1.0 HF-8 (OM 5.1.0 HF-8) to TIBCO® Order Management 6.0.0 HF-3 (OM 6.0.0 HF-3) version by using any of the following procedures.

Note: Migration of orders from multi-tenant databases is supported without any configuration or restarting the services.
Note: Migration for Jeopardy and Order Messages is not supported.
Before you begin
Note: If you migrate the database from any previous version to the 6.0.0_HF-3 version, you have to republish the catalog.

The messages, corresponding to the in-process orders in TIBCO® Fulfillment Order Management 4.0.2 HF-12, TIBCO® Order Management - Long Running 5.0.0 HF-5, or TIBCO® Order Management 5.1.0 HF-8, are not be allowed to remain in the pending state on the queues mentioned in the following section. These messages must be processed before upgrading. However, there are a couple of queues on which messages can remain pending.

    Procedure
  1. Stop the northbound system (for example, Siebel CRM), which sends the order request messages to TIBCO® Order Management for fulfillment. Doing this, it ensures that there are no new order messages coming on the tibco.aff.oms.ordersService queue. All the existing messages must be processed by the OMS server component.

  2. Stop the southbound process component systems, which are integrated with Order Management for processing various requests for plan items such as execute request, suspend request, activate request, and milestone release request. Doing this ensures that there are no messages pending on the following queues. All the existing messages must be processed by the OMS server component in the older version of the product from where you are migrating.

    • tibco.aff.orchestrator.planItem.execute.reply

    • tibco.aff.orchestrator.planItem.suspend.reply

    • tibco.aff.orchestrator.planItem.milestone.notify.request

    Ensure that there are no new messages coming from process components on the following queues associated with the JMS-based data access interfaces, which are used to get the order data and get or set the plan/plan item data. All the existing messages must be processed by the OMS server in the older version of the product from where you are migrating.

    • tibco.aff.tds.order.read.request

    • tibco.aff.tds.plan.request

    • tibco.aff.tds.plan.read.request

  3. Ensure that there are no messages pending on the following queues related to the various types of order requests submitted to the Orchestrator:

    • tibco.aff.orchestrator.order.suspend

    • tibco.aff.orchestrator.order.activate

    • tibco.aff.orchestrator.order.withdraw

  4. If the order feasibility check is enabled in the Orchestrator configuration, ensure that there are no messages pending on the following queues. The external feasibility provider component must process all the request messages and the orchestrator must process all the reply messages.

    • tibco.aff.orchestrator.provider.order.feasibility.request

    • tibco.aff.orchestrator.provider.order.feasibility.reply

  5. Ensure that there are no messages pending on any of the following queues that are used for the integration between Orchestrator and the AOPD components for execution plan generation. (This point is not applicable when you are migrating from OM 5.1.0 HF-8.)

    • tibco.aff.orchestrator.provider.order.opd.request

    • tibco.aff.orchestrator.provider.order.opd.reply

  6. If order prequalification handling is enabled in the Orchestrator configuration, ensure that there are no messages pending on the following queues. The external prequalification failed request handler must process all the request messages and the orchestrator must process all the reply messages.

    • tibco.aff.orchestrator.provider.order.prequal.failed.request

    • tibco.aff.orchestrator.provider.order.prequal.failed.reply

  7. Ensure that there are no messages pending on any of the following queues that are used for integration between Orchestrator and the external plan item error handler component for processing the failed plan item requests.

    • tibco.aff.orchestrator.provider.planItem.failed.request

    • tibco.aff.orchestrator.provider.planItem.failed.reply

    Considering the pending messages on all the earlier mentioned queues are processed by the respective components of FOM 4.0.2 HF-12, OM-LR 5.0.0 HF-5, or OM 5.1.0 HF-8.

    Messages can be pending on the following queues. These are the outbound queues for the Orchestrator to send various requests for plan items to the process components. The messages on these queues are processed once the process component systems are started after the upgrade.

    • tibco.aff.orchestrator.planItem.execute.request
    • tibco.aff.orchestrator.planItem.suspend.request
    • tibco.aff.orchestrator.planItem.activate.request
    • tibco.aff.orchestrator.planItem.milestone.release.request

    If the requestReply header property is set to false in the GetOrder, GetPlan, GetPlanItem, SetPlan, or SetPlanItem data access requests, there can be pending messages on the following queues:

    • tibco.aff.tds.order.reply

    • tibco.aff.tds.plan.reply

    If the requestReply header property is set to true, messages can be pending on the queues passed as replyTo destinations in the requests. These are also the outbound queues for the OMS server and the pending messages on these queues are also processed once the process component systems are started after the upgrade.

    After ensuring that no further processing is going on in any of the servers of the older version of the product from where you are migrating, they can be shut down. Also, shutdown all the external components, such as feasibility provider, pre-qualification failed request handler, external OPD, plan item error handler component.

Backing up the Database and EMS Messages

It is a best practice to back up the database when migrating from OM 5.1.0 HF-8. You can skip this when migrating from FOM 4.0.2 HF-12 or OM-LR 5.0.0 HF-5.

You must back up the pending EMS messages when you are migrating from any of the versions.

Installing TIBCO® Order Management 6.0.0 HF-3

Download the TIBCO Order Management6.1.0 build from TIBCO eDelivery and extract the TIB_om_6.0.0-HF-3.zip file to the OM_HOME folder. See "Installation and Deployment" of the TIBCO® Order Management Installation and Configuration..

Upgrading Database from OM 5.1.0 HF-8 to 6.0.0-HF-3

To upgrade the database from 5.1.0 HF-8 to 6.0.0-HF-3, perform the following procedures.

PostgreSQL

Admin Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/postgreSQL/admin/bin/postgres_admin_db.properties file and update the values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/postgreSQL/admin/bin directory, run the following scripts:

    • upgrade_5.1.0_to_6.0_db-setup.sh

    • upgrade_6.0.0_to_6.0.0hf1_db_setup.sh

    • upgrade_6.0.0hf1_to_6.0.0hf2_db_setup.sh

    • seed_common_authConfig_db_setup.sh

    • export_time_scheduler_table_data_db-setup.sh (For more information, see the README_FOR_EXPORTING_TIME_SCHEDULER_DATA.txt file before running this script.)

Archival Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/postgreSQL/archival/bin/postgres_archival_db.properties file and update the values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/postgreSQL/archival/bin directory, run the following scripts:

    • upgrade_5.1.0hf7_to_6.0_db-setup.sh

    • upgrade_6.0.0_to_6.0.0hf1_db-setup.sh

    • upgrade_6.0.0hf2_to_6.0.0hf3_db-setup.sh

Catalog Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/postgreSQL/catalog/bin/postgres_catalog_db.properties file and update the values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/postgreSQL/catalog/bin directory, run the following scripts:

    • upgrade_5.1.0_to_6.0_db-setup.sh

    • upgrade_6.0.0hf2_to_6.0.0hf3_db_setup.sh

Jeopardy Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/postgreSQL/jeopardy/bin/postgres_jeopardy_db.properties file and update the values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/postgreSQL/jeopardy/bin directory, run the following script:

    • upgrade_5.1.0hf7_to_6.0_db-setup.sh

Order Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/postgreSQL/order/bin/postgres_order_db.properties file and update the values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/postgreSQL/order/bin directory, run the following scripts:

    • upgrade_5.1.0hf7_to_6.0_db-setup.sh

    • upgrade_6.0.0_to_6.0.0hf1_db-setup.sh

    • upgrade_6.0.0hf1_to_6.0.0hf2_db-setup.sh

    • upgrade_6.0.0hf2_to_6.0.0hf3_db-setup.sh

    • import_time_scheduler_table_data_db-setup.sh (For more information, see the README_FOR_IMPORT_TIME_SCHEDULER_DATA.txt file before running this script.)

User Database

    Procedure
  1. Open the $OM_HOME/db/dbscripts/postgreSQL/user/bin/postgres_user_db.properties file in a suitable editor and update the values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/postgreSQL/user/bin directory, run the following script:

    • db-setup.sh

Oracle

Admin Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/oracle/admin/oracle_admin_db.properties file and update the following values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/oracle/admin directory, run the following scripts:

    • upgrade-5.1.0hf7-to-6.0_db-setup.sh

    • upgrade_6.0.0_to_6.0.0hf1_db_setup.sh

    • upgrade_6.0.0hf1_to_6.0.0hf2_db_setup.sh

    • seed_common_authConfig_db_setup.sh

    • order_user_grant_permission_db_setup.sh (For more information, see the README_FOR_GRANT_ORDER_USER_PERMISSION.txt file before running this script.)

Archival Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/oracle/archival/oracle_archival_db.properties file and update the following values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/oracle/archival directory, run the following scripts:

    • upgrade_5.1.0hf7_to_6.0_db-setup.sh

    • upgrade_6.0.0_to_6.0.0hf1_db-setup.sh

    • upgrade_6.0.0hf2_to_6.0.0hf3_db-setup.sh

Catalog Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/oracle/catalog/oracle_catalog_db.properties file and update the following values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/oracle/catalog directory, run the following scripts:

    • upgrade-5.1.0hf7-to-6.0_db-setup.sh

    • upgrade_6.0.0hf2_to_6.0.0hf3_db_setup.sh

Jeopardy Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/oracle/jeopardy/oracle_jeopardy_db.properties file and update the following values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/oracle/jeopardy directory, run the following script:

    • upgrade_5.1.0hf7_to_6.0_db-setup.sh

Order Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/oracle/order/oracle_order_db.properties file and update the following values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/oracle/order directory, run the following scripts:

    • upgrade-5.1.0hf7-to-6.0_db-setup.sh

    • upgrade_6.0.0_to_6.0.0hf1_db-setup.sh

    • upgrade_6.0.0hf1_to_6.0.0hf2_db-setup.sh

    • upgrade_6.0.0hf2_to_6.0.0hf3_db-setup.sh

    • import_time_scheduler_table_data_db-setup.sh (For more information, see the README_FOR_TIME_SCHEDULER_DATA_FROM_ADMIN_TO_ORDERDB.txt file before running this script.)

User Database

    Procedure
  1. In a suitable editor, open the $OM_HOME/db/dbscripts/oracle/user/oracle_user_db.properties file and update the following values. For more information, see "Task 2: Creating the Database" of the TIBCO® Order Management Installation and Configuration.

  2. From the $OM_HOME/db/dbscripts/oracle/user directory, run the following script:

    db-setup.sh

Upgrading the TIBCO EMS Channel

To upgrade the EMS channel from TIBCO® Fulfillment Order Management 4.0.2 HF-12 to TIBCO® Order Management 6.0.0 HF-3, run the following command:

$ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_FOM4.0.2HF12_to_6.0.0.txt 
$ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0_to_6.0.0-HF1.txt $ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0-HF1_to_6.0.0-HF2.txt $ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0-HF2_to_6.0.0-HF3.txt

To upgrade the EMS channel from TIBCO Order Management - Long Running 5.0.0 HF-5 to TIBCO® Order Management 6.0.0 HF-3, run the following command:

$ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_5.0.0-LR-HF5_to_6.0.0.txt 
$ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0_to_6.0.0-HF1.txt $ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0-HF1_to_6.0.0-HF2.txt $ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0-HF2_to_6.0.0-HF3.txt

To upgrade the EMS channel from TIBCO® Order Management 5.1.0 HF-8 to TIBCO® Order Management 6.0.0 HF-3, run the following command:

$ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_5.1.0-HF7_to_6.0.0-HF0.txt 
$ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0_to_6.0.0-HF1.txt $ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0-HF1_to_6.0.0-HF2.txt $ tibemsadmin -server tcp://localhost:7222 -user admin -script $OM_HOME/ems/UpgradeEMSChannel_6.0.0-HF2_to_6.0.0-HF3.txt

If you do not want to use jeopardy queues, run the DeleteJeopardyEMSChannel.txt script.

Merging Configurations from OM 5.1.0 HF-8 to OM 6.0.0 HF-3

The following applicationIds are renamed to make them more readable:

  • Data service is renamed to data-service

  • omsui is renamed to oms-ui

These applicationIds must now be updated in the back-end store as well. To update the applicationIds for the existing configuration, complete the following steps:

    Procedure
  1. Use the GET APIs to download the configuration files and application properties for the mentioned APIs.

  2. Use the DELETE APIs to delete the existing applications (data service and omsui)

  3. Upload the downloaded configuration files again and upload the latest application properties from the $OM_HOME/seed-data/app-properties directory and reconfigure as per the existing values for the new applicationIds.

  4. Configure all other applications again as per your requirements.

Merge the previous configurations with the current configurations. For more details, see "Task 8: Uploading Metadata file, App Properties, Config Files through Configurator UI" and "Task 9: Configuring minimum requirements through Configurator UI" of the TIBCO® Order Management Installation and Configuration.

  • Change the defaultAckMode property value for the "common" configuration. Here possible values are REST and MESSAGING.

  • Change the authorizationServiceTokenEndPoint property value from http://localhost:9091/oauth/token to http://localhost:9091 for "common" configuration.

  • Change the migrationURL property value for the Orchestrator configuration > 'Migration Service Configurations' category.

  • Delete the configurations from $OM_HOME/samples/PayLoadJson/deletePayLoads/deletePayload-files 510HF8-to-60HF3. Use the DELETE API to delete the mentioned configurations for the mentioned services.

  • Add the configurations from $OM_HOME/samples/PayLoadJson/addPayLoads/addPayload-files 510HF8-to-60HF3. Use the POST API to add the mentioned configurations for the mentioned services.

Note:
  • You cannot migrate orders that are in OPD status. To migrate such orders, ensure that the orders have passed the OPD state.

  • When the same order ID is present in both Order Management - Long Running 5.0.0 HF-5/Fulfillment Order Management 4.0.2 HF-12 and Order Management 5.1.0 HF-8, the order of the latter gets replaced during migration.

  • Audit trail logs for final state orders are migrated, but audit trail logs for in-progress orders are not seen after migration. If you do some action on Order Management 6.0.0 HF-3 orders, then only the log is generated and seen on the UI.

  • Catalog is not migrated. You need to reload models on Order Management 6.0.0 HF-3

Whether you are migrating from FOM 4.0.2 HF-12 or OM-LR 5.0 HF-5, all the above steps are mandatory for both online and offline migration. Once you have completed all the aforementioned steps, you can start the following services from Order Management 6.0.0 HF-3:

  • Orchestrator

  • AOPD

  • Archival

  • DataService

  • OMS UI

  • Migration Service

  • Catalog

FOM 4.0.2 HF-12 or OM-LR 5.0.0 HF-5 to OM 6.0.0 HF-3

Offline Migration

This process is called as offline migration, because before you start using the Orchestrator from Order Management 6.0.0 HF-3, you need to complete the migration. This is an on-demand process. You can choose which orders to migrate and which one to not.

    Procedure
  1. Set the database properties from the source version in the oracle_migration_db.properties or postgres_migration_db.properties file under the $OM_HOME/db/dbscripts/migration_from_Legacy_To_6.0.0 folder.
  2. Run the db-setup.sh script from the $OM_HOME/db/dbscripts/migration_from_Legacy_To_6.0.0/postgreSQL or $OM_HOME/db/dbscripts/migration_from_Legacy_To_6.0.0/oracle directory.
    This script creates the MIGRATED_ORDERS table in the Order Management - Long Running 5.0.0 HF-5 or Fulfillment Order Management 4.0.2 HF-12 database, which is used to track the orders that are migrated.
  3. On the Configurator UI, navigate to Migration service > App properties.
    1. Select a Admin Data Source Configuration for legacy Application category and provide admin database property details of the source from where the migration is done.
    2. Select a Data Source Configuration for legacy Application category and provide the default tenant database property details of the source from where the migration is done.
    3. Select a Messaging Configuration category and provide the properties details of the source from where the migration is done.
      Note: The current EMS and the source version must be the same.
    4. Select a Archival Database Configurations for 6.0 Application category and provide property details from the current database.
    5. Select a Order Data Source Configuration for 6.0 Application category and provide property details from the current database.
    6. (Optional) Select a Migration Functional Configuration category and set the value of the com.tibco.offlineMigration.migrateOrderInFinalState flag as true to migrate the final state (CANCELLED, COMPLETE) orders.
  4. Navigate to the $OM_HOME/roles/om-migration/standalone/config directory and update the application.properties file for configuratorServiceUrl (value is the IP or DNS name of the configurator service).

  5. To start the Migration service, navigate to the $OM_HOME/roles/om-migration/stanalone/bin directory and run the ./start.sh script.

  6. To access the Swagger REST API, enter the following endpoint in a browser: http://localhost:9100.

  7. On the /migration/order endpoint, run the request to migrate orders. You can enter various criteria such as orderID, orderRef, or dateRange.

    Sample:

    {
      "orderID": "string",
      "orderRef": "string",
      "dateRange":
    
    {     "startDate": "2023-01-24T18:31:57.274Z",     "endDate": "2023-01-24T18:31:57.274Z"   }
    ,
      "status": [
        "string"
      ],
      "headerUdfs": [
       
    
    {       "name": "string",       "value": "string"     }
      ],
      "orderLineUdfs": [
       
    
    {       "name": "string",       "value": "string"     }
      ]
    }
  8. Start the other services. See "Task 10: Starting or Restarting the Services" of the TIBCO® Order Management Installation and Configuration.

  9. Start the southbound system so that the Orchestrator service can start processing these messages.

  10. Once you observe that the existing messages for the in-flight orders has been fulfilled by the orchestrator, start the new incoming orders flow from the northbound system.

ResultThe in-progress orders are migrated to the order database and Archival database and the final state orders are migrated to the Archival database. If Order Sequencing is enabled (com.tibco.fom.orch.enableOrderSequencing is set as TRUE), the in-progress sequenced orders are migrated one by one to the order database and Archival with Order Status as Blocked.

Online Migration

This process is called as online migration, because the in-flight orders from the source version can be processed in 6.0.0 HF-3 version directly. You have to stop the services from the source version of the product to start with the online migration process.

Online migration is performance intensive as the in-flight orders are migrated on the fly. For each in-coming message processing from southbound, there is a call to Migration service from the orchestrator.

    Procedure
  1. Set the database properties from the source version in oracle_migration_db.properties or postgres_migration_db.properties file under the $OM_HOME/db/dbscripts/migration_from_Legacy_To_6.0.0 folder.
  2. Run the db-setup.sh script from the $OM_HOME/db/dbscripts/migration_from_Legacy_To_6.0.0/postgreSQL or $OM_HOME/db/dbscripts/migration_from_Legacy_To_6.0.0/oracle directory.
    This script creates MIGRATED_ORDERS table in Order Management - Long Running 5.0.0 HF-5 or Fulfillment Order Management 4.0.2 HF-12 database, which is used to track the orders that are migrated.
  3. Set the migrationEnabled flag value as true and set the migrationURL to http://<host>:9100/migration/order from the configurator UI for the orchestrator application > 'Migration Service Configurations' category.
  4. Once you configure the above mentioned property, restart the Orchestrator service.

  5. Start the southbound system so that the orchestrator service can start processing these messages.

  6. Once you observe that the existing messages for the in-flight orders has been fulfilled by Orchestrator, start the new incoming orders flow from the northbound system.

Offline-Online Combined

Both the online and offline migration services have their own advantages and disadvantages. To overcome that, it is a best practice to use them together as per your requirements. For the in-flight orders, online migration is best suited. For some of the orders that stay pending for a long duration, offline migration is more useful.

OM 5.1.0 HF-8 to OM 6.0.0 HF-3

Migrating orders from OM 5.1.0 HF-8 to OM 6.0.0 HF-3

    Procedure
  1. Run the following APIs from the Migration service to migrate orders from 5.1.0 HF-8 to 6.0.0 HF-3.

    • Populate Order Status

      End point: /order/status

      Method: POST

      Request sample:

      {
        "sortCriteria": {
          "sortFields": [
            {
              "field": "ORDER_ID",
              "sortBy": "ASC",
              "sortSequence": 0
            }
          ]
        },
        "orderID": [
          "string"
        ],
        "orderRef": [
          "string"
        ],
        "dateRange": {
          "startDate": "2024-02-27T10:31:33.064Z",
          "endDate": "2024-02-27T10:31:33.064Z"
        },
        "status": [
          "START, BLOCKED, PENDING, OPD, OPDERROR, EXECUTION, COMPLETE, CANCELLED, SUSPENDED, SUSPENDING, PREQUALIFICATIONFAILED, WITHDRAWN, FEASIBILITY"
        ],
        "filterOperator": "IN"
      }
    • Migrate Order Scxml

      End point: /order/scxml/migration

      Method: POST

      Request sample:

      {
        "sortCriteria": {
          "sortFields": [
            {
              "field": "ORDER_ID",
              "sortBy": "ASC",
              "sortSequence": 0
            }
          ]
        },
        "orderID": [
          "string"
        ],
        "orderRef": [
          "string"
        ],
        "dateRange": {
          "startDate": "2024-02-27T10:31:51.969Z",
          "endDate": "2024-02-27T10:31:51.969Z"
        },
        "status": [
          "START, BLOCKED, PENDING, OPD, OPDERROR, EXECUTION, COMPLETE, CANCELLED, SUSPENDED, SUSPENDING, PREQUALIFICATIONFAILED, WITHDRAWN, FEASIBILITY"
        ],
        "filterOperator": "IN"
      }

Migrating audit trails from 5.1.0 HF-8 to 6.0.0 HF-3

    Procedure
  1. Run the following API from the Migration service to migrate audit trails from 5.1.0 HF-8 to 6.0.0 HF-3.

    Migrate audit trail data

    End point: /migration/auditTrail_510hf8_60hf3/

    Method: POST

    Request sample:

    {
      "sortCriteria": {
        "sortFields": [
          {
            "field": "ORDER_ID",
            "sortBy": "ASC",
            "sortSequence": 0
          }
        ]
      },
      "orderID": [
        "string"
      ],
      "orderRef": [
        "string"
      ],
      "dateRange": {
        "startDate": "2024-02-27T10:29:29.018Z",
        "endDate": "2024-02-27T10:29:29.018Z"
      },
      "status": [
        "START, BLOCKED, PENDING, OPD, OPDERROR, EXECUTION, COMPLETE, CANCELLED, SUSPENDED, SUSPENDING, PREQUALIFICATIONFAILED, WITHDRAWN, FEASIBILITY"
      ],
      "filterOperator": "IN"
    }