GUIDs Performance with Data Migration

This process is optional. There is no need to convert records using this process to obtain proper functionality with the GUID feature on or off.

The GUIDs performance feature is built to be compatible with earlier releases. Errors do not occur if legacy records are not converted. However, if legacy records are not converted, then an extra write DML operation may occur during transactions that creates additional records in the same container. A container can be an:

• Account containing assets

• Order containing OrderItems

• Quote containing QuoteLineItems

• Opportunity containing OpportunityLineItems

For example, if legacy assets are not converted and the GUID feature is enabled, performance benefits are still the same for any resulting Asset-to-Order operation because, for example, the order is entirely new even though it was modeled after the existing unconverted Assets. The new order line items in the new order can use GUIDs without violating the mixing rule and obtain improved performance as a result.

However, if one or more order items are added to the order and the order is submitted, the resulting submit operation incurs an extra, potentially costly, DML write operation. The reason is that the relevant target container in this operation is the existing Account that already has unconverted assets. To avoid violating the mixing principle, the code must then write the new assets using Salesforce IDs, which requires a separate write operation.

Options for GUIDConverterBatchProcessor

The options for the GUIDConverterBatchProcessor are supplied through the constructor, as in the example above. These options are:

• Parameter #1: Container Name

  This parameter can be one of the following:

  • Account -- for Asset scanning or conversion.

  • Order -- for OrderItem scanning or conversion.

  • Quote -- for QuoteLineItem scanning / conversion.

  • Opportunity -- for OpportunityLineItem scanning / conversion.

  If Account is specified then Assets are scanned or converted, depending on the option you chose in the second parameter, for each Account in the system. Similarly, if Order is specified, then OrderItem records are scanned, etc.

• Parameter #2: Option

  This parameter can be any of the values specified in the GUIDConverterBatchProcessor.Options enum:

  • COUNT_ONLY

    • Scans the record types indicated by the first parameter.

    • Returns a count of the number of containers that need conversion in the response email.

    • Does not modify data.

  • SUPPLY_IDS_ONLY

    • Scans the record types indicated by the first parameter.

    • Returns a count of the number of containers that need conversion and specifies the Salesforce ID values of those containers in the response email.

    • Does not modify data.

  • CONVERT

    • Scans and converts the record types indicated by the first parameter.

    • Returns a count of the containers converted and a list of the Salesforce IDs of any container that could not be converted due to an error condition.

    • If any containers require conversion, related hierarchy fields vlocity_cmt__ParentItemId__c and vlocity_cmt__RootItemId__c are modified in the related line item records.

• Parameter #3: Container Skip List

  This parameter is optional. It can be null. If specified, this parameter must be a list of containers IDs that should not be scanned or converted during the run. The intended use is null unless a problematic container, such as Account, was identified during a previous batch job. Such containers are identified by ID in the response email and can be supplied to the constructor so they do not affect the processing of other containers.

Governor Limits and Need for Limiting Batch Size

Apex batch job execution is subject to governor limits that are similar to those for other transaction types for each batch execution. For the GUIDConverterBatchProcessor, a batch is a number of containers specified by ID. That batch size is controlled by an optional second parameter to the Database.executeBatch() call but defaults to 200.

If you encounter governor limit exceptions while executing the batch process, try reducing the batch size by passing, for example, 100 as the second parameter to Database.executeBatch()).