Migrating to V2 availability API

Edit online

If you are currently subscribed to Inventory Visibility V1 availability API, you can migrate to the Inventory Visibility V2 availability API.

This section provides the required information to help you migrate efficiently. As part of this migration, new node availability, network availability, and reservation APIs are introduced along with other V2 availability APIs.

About this task

Important: When you migrate to V2, you cannot switch back to V1, and you cannot use V1 availability and reservation APIs.

Procedure

  1. Premigration phase

    If you are using V1 of availability APIs, you might decide to move to V2 to use the benefits added in V2 APIs.

    1. During this phase, you can raise an operation ticket through IBM support to migrate from V1 to V2. This phase is referred to as v1AvailMode.
    2. Before migrating, you must have the new Cloud Object Storage bucket that is configured for new V2 events according to New event formats. To avoid any new availability event loss when migration is complete, you must be ready with any implementation changes required to call new APIs and use the new response and events. When the support team confirms that Inventory Visibility migration is complete and Inventory Visibility is moved to v2AvailMode, you can start to use V2 APIs and events.

      Also, refer to the New API response formats and New event formats for any customization updates.

    3. The V2 availability requests support both requestedEndTs and requestedQuantity fields. In V1 availability APIs, the available quantity is placed onhand or in future field, based on the response of supplyType. In V2, it is entirely based on the ETA of supply. If the ETA of supply is in future, then it will be accounted in future availability window otherwise it is accounted for in the current availability window in the response. For more information, see Key differences between V1 and V2 APIs.
  2. Migration phase

    While your environment is being migrated to V2, you can continue to use V1 APIs. V2 APIs are not supported in this phase as data might be in an incomplete state. This phase is referred as preferV1AvailMode. Only availability records are migrated from old table to the new table. For Sterling Order Management System customers, this phase covers the Sterling Order Management System adapter migration as well. When migration is complete, IBM support communicates that environment is ready to be moved to v2AvailMode through the support ticket.

    Note: Before migrating to V2, any active distribution group level reservations that are already placed should either be expired or consumed as V2 does not support distribution group level reservations.
  3. Post-migration phase
    Your environment is now ready with V2 APIs. These new sets of APIs have many benefits over V1. For more information, see Benefits of migrating to V2 topic. This phase is referred to as v2AvailMode.
    Note: All new customers start with v2AvailMode.

    In the post-migration phase, the V1 availability and reservation APIs will no longer be accessible. You can access only V2 APIs in this phase. As mentioned in the premigration phase, the changes in the systems that call IV APIs or consume IV events must be applied at this stage.

    Important: To ensure minimal disruption to the systems, it is recommended that you plan for downtime when you are switching from V1 to V2 API URLs.