Configuring Archive Service integration

Sterling Order Management System Software archives orders as orderLine, orderAudit, and order parts.

Depending on the data size of each part, the archival process is divided in multiple batches of archive request considering the batch size that is configured in osi.archive.order.<partname>.batch.size or osi.archive.max.batch.data.size property. Based on the configuration, a minimum of one record of any part is sent in one batch of the archival request, and cannot be further sliced.

After successfully archiving the other parts, order part gets archived. With order part archival, the order status in Order Search is updated to archived by Archive Service.

Your business might demand to archive any other order-related details separately such as payment, hold, and so on in the Archive Service for any of the following reasons:
  • Access a particular order detail separately in Archive Service rather than fetching the whole data.
  • For large orders, reduce the size of data in one archive request and improve the performance in Archive Service.
To archive any other order-related details separately, complete the following steps:
  1. Identify the additional parts
    Identify all order-related entities that must be archived as a separate part.
    Note: To archive the order-related entities separately, you can use only the direct subordinate entities of an order. For example, payment, hold, and so on. For subordinate child entities of an order line, you cannot archive separately. For example, OrderLineInvAttRequest, Schedules, and so on. These entities are subordinate entities of an order line that cannot be specified as a separate part.
    Note: The order address-related data that is stored in the YFS_Person_Info table such as PersonInfoShipTo, PersonInfoBillTo, and so on cannot be archived to a separate order part in Order Service.
  2. Configure the additional parts

    Configure the osi.archive.order.additional.parts property and specify the table names of entities that are identified to archive as separate parts. For example, to define payment and hold as separate parts, configure the following property.
    osi.archive.order.additional.parts=YFS_PAYMENT, YFS_ORDER_HOLD_TYPE

  3. Configure the additional part names
    To specify the part name for entities, configure the osi.archive.order.part.<tablename>.name property.
    Note: It is mandatory that you specify the part name for additional parts that are identified. Also, configure those part names in Archive Service by using the corresponding property.
    For example, to define the part name for payment and hold, configure the following properties:
    • osi.archive.order.part.YFS_PAYMENT.name=payment
    • osi.archive.order.part.YFS_ORDER_HOLD_TYPE.name=orderHold
    Note: You can give any name as a part name, and define the same part names in Archive Service to ensure that orders are archived with the new parts. Data related to additional parts are archived and accessed by using the defined part name in Archive Service.
  4. Configure the batch Size

    The subordinate entities, orderLine and orderAudit of an order, which are the default parts, define the batch size by configuring the osi.archive.order.orderLine.batch.size and osi.archive.order.orderAudit.batch.size properties. For example, define osi.archive.order.orderLine.batch.size=5 and osi.archive.order.orderAudit.batch.size=10

    For all the other additional parts that are defined in the earlier steps, ensure to configure the osi.archive.order.<partname>.batch.size property. For example, to define the batch size for additional parts, which are payment and hold, configure osi.archive.order.payment.batch.size=3 and osi.archive.order.orderHold.batch.size=2
    Note: It is not mandatory that you configure the batch size for the default and additional parts. If you do not define the batch size for any part name, then all the records for those parts are sent in a single archive batch request.
  5. Dynamic batching of additional parts
    In addition to the batch size that is defined for additional parts, the Archive Service provides the capability to prepare batches dynamically for archival based on the memory size of the data for the current order. To archive maximum data in a single batch archival request, configure the osi.archive.max.batch.data.size property.
    Note: When you define both batch size and batch data size properties, the Archive Service considers the property for which the criteria is first met. The following scenario explains this behavior.

    Consider an order that contains 100 lines. You have configured the batch size for the order line part as osi.archive.order.orderLine.batch.size=20 and the batch data size as osi.archive.max.batch.data.size=100 in kilobytes.

    While preparing the data, the Archive Service combines the data one by one for all the order lines by checking the batch size and batch data size as configured. While combining the data for the first 20 order lines, if the Archive Service identifies that the total data size is 50 kilobytes, and it can accommodate more data in a batch, as the batch size is configured as 20 it starts archiving the data and creates a new batch for rest of the data.

    Now let say while combining the data for the next 10 order lines, if the Archive Service identifies that the total batch data size is 99 kilobytes and by combining a new line will make it more than the defined batch data size, then even if more lines can be accommodated as per the batch size, the Archive Service immediately attempts to archive the data and creates a new batch for rest of the data.

  6. Archive the hangoff entities
    You can archive data for the hangoff entities along with their parent entities data without any additional step for this activity.
    Note: Ensure that you do not specify the hangoff entities as additional parts.
  7. Archive the non-hangoff custom table data
    If your business has implemented to store order and order line entities related data in custom tables, which do not have defined relationship in Sterling Order Management System Software, use the following user exits to supply data related to those tables to the Order Archive agent.
    • OSIGetExternalOrderArchiveInputUE - Called for each order to retrieve data from the order related custom tables.
    • OSIGetExternalOrderLineArchiveInputUE - Called for each order line to retrieve data from order line related custom tables.
    • OSIArchiveSuccessExternalActionUE - Called after the successful archival of order details, provided if OSIGetExternalOrderArchiveInputUE or OSIGetExternalOrderLineArchiveInputUE is implemented and has returned custom data for archival.

    For more information about these user exits, see Javadoc.

For more information about the Archive Service yfs properties to configure, see Order Archival yfs.properties.