Order Management Plus Only: Patch Releases

999.30

Previously, failed orchestration items could be permanently stuck in a running state if a subsequent notification failed, preventing retries. The fix now performs the status update and notification in a single step. If the step fails, the status is automatically reset for a retry. Consistently failing tasks are marked as fatally failed to stop endless attempts.

999.29

Previously, during an AWS Blue/Green RDS upgrade, the green database instance sometimes entered a degraded state upon worker pod restarts. This was due to Data Definition Language (DDL) statements attempting to recreate existing tables. The issue is now fixed by adding a conditional check to ensure table creation DDL statements only execute if the table doesn't already exist.

999.28

• Additional debug logs are added for fetching the system instance state during callout processing.
• The caching mechanism is improved to store only the system instance state, rather than the entire record.

999.27

Previously, push events experienced premature time outs if the timeout value defined in the corresponding orchestration item definition exceeded the maximum integer value supported by PostgreSQL. This issue is now resolved.

999.26

Previously, Order Management Plus resources used Web Application Firewall (WAF) Classic. Now, Order Management Plus resources use WAF v2 WebACL that supports the updated WAF rules and features for enhanced security.

999.25

Previously, the incoming pod generated a high volume of debug logs, leading to log rotation issues and missed data in Sumologic. To resolve this, debug logs are disabled, and info-level logs are implemented to capture key events by default.

999.24

• In the past, when an order was amended and a new amend plan was generated, the system failed to update the status of orchestration items that were on hold. This has been fixed, and now the status automatically changes to either Pending or Discarded, depending on the specifics of the amend order.
• Previously, consumer threads were unable to process all the polled payloads from a Kafka topic partition within the heartbeat interval due to retries. This led to consumer rebalancing, causing multiple consumer threads to send the same payload for processing, which in turn delayed notifications to ODIN. This issue has been fixed by ensuring that the consumer thread completes the processing of all polled payloads within the heartbeat interval.
• Previously, the condition evaluation for orchestration items took into account all associated order items. After the fix, the system now considers only the latest supplemental order items if they are associated with the orchestration item. If no supplemental order items are associated, all order items are considered.

999.22

• Previously, when a supplemental order was canceled before submission, the Frozen-Running orchestration items didn't execute after the status changed to Running, resulting in the plan execution getting stuck. Now these orchestration items are executed, allowing the plan to progress to completion.
• This patch introduces multiple order reconciliation to ODIN by allowing the entry of a list of orders in the request. Previously, the reconciliation API only supported a single order request.
• This patch introduces a new API for fetching the ODIN notification failures.

999.21

• Previously, the system stored records of the processed orders in memory, which led to an out-of-memory error while processing new orders later. This has been fixed.
• Previously, when a order was canceled, callout in the orchestration continued to be in a running state instead of timing out or completing. This issue occurred due to a race condition between the timeout handler and the HTTP response handler's error handling flow. This issue has been fixed.
• This patch introduces /ordermanagement/v1/orders/ API to monitor orchestration stage of orders that are in progress. This API returns the state of active orchestration items for an order using the Salesforce order ID.

999.20

• Previously, when the encryption restarted, the characteristic encryption or decryption requests resulted in an error, causing order rejections and request failures without retries. Now, these issues are fixed with the changes:
  • The incoming pod retries order for decomposition.
  • The completer pod retries requests to the encryption service up to three times.
  • The custom pods have the option to enable retries to the encryption service. To enable retries, add the property xom.encryption-client.retries to the application.properties file in the application. For example, set xom.encryption-client.retries = 2 to have two retries for encryption or decryption calls.
• Previously, the UI API calls failed during API request spikes. This has been fixed.
• Previously, incoming pods rejected orders if the pod shutdown was triggered during order decomposition. This has been fixed.
• Previously, ODIN API calls were not processed due to transient connection issues from Org and retries for these errors were unavailable. This issue has been fixed.
• Previously in Order Management Plus, a user was able to modify characteristic values even when the user's profile modification access was disabled.This has been fixed.
• An option to configure the batch size of orchestration items is now added to resume a system instance that is on hold.

999.19

Previously, the system reset the OOTB objects during deployment. Now, these objects don’t ‌reset during ‌deployment if they were modified by the user.

999.18

Previously, Users could not be deactivated in OMPL when synced. Now, Users can be deactivated in OMPL by setting the OMplusSyncEnabledfield to false.

999.17

This patch improves the catalog caching layer performance.

The JDBC connection pool is used for getting connections to the database for querying or modifying data. This patch introduces a new worker planner to efficiently use the JDBC connection pool. Enable this planner if you have database connection timeout issues in the worker pods. Enable the settings xom.worker.planner.version=v2 and spring.datasource.hikari.maximumPoolSize=19 for the worker.

Patch 999.16

No release.

Patch 999.15

No release.

Previously when a product with Account scope and a characteristic change was moved, Order Management Plus marked the action as No Change. Now, the action is marked as Modify, with an empty sub action.

Patch 999.14

Some intermittent Kafka errors like "ProducerFencedException" resulted in orders getting rejected. This issue has been fixed.

For provisionally accepted supplemental orders, Order Management Plus used to send a Rejected notification twice. This issue has been fixed now.

Patch 999.13

In some scenarios, the plan could be completed even when there were some running orchestration items. This issue has been fixed.

This patch allows users to view the Actual Number Of Retries field as a column on the manual task page.

Patch 999.12

This patch introduces socket timeouts for ODIN notifications api calls. Previously, there was no timeout, so threads could end up being stuck.

Previously, the Worker Manager in OM only supported deployment yaml, but not a list of deployments. With this patch, the Worker Manager supports deployment and lists of deployment.

This patch introduces socket timeouts for ODIN notifications api calls. Previously, there was no timeout, so threads could end up being stuck.

This patch introduces better logging of ODIN notification failures. This logging makes it easier and faster to resync the order status to ODIN in the case of a failure.

Before this patch, when a long-running order was retried, OM sometimes restarted the entire order process unnecessarily. This restart affected performance. With this patch, before OM restarts an entire order, it verifies that it must do so.

This patch provides improved performance when running a global search by name in the Vlocity Order Management Plus Admin page. For example, performance in the past was too sluggish to show results in the interface when searching by order or orchestration plan name. Now those results are shown.

OM uses kafka2streaming for compatibility with customer workflows that also use it. Previously, kafka2streaming would sometimes get stuck in an endless loop if it couldn't successfully complete CPQ cart cancel. This patch fixes that issue. OM now logs an error in the kafka2streaming pod, and skips the payload so that kafka2streaming does not get stuck.

Previously, long-running orders that needed to retry would do so repeatedly without a pause between retries. This repeated retrying sometimes led to performance issues. This patch introduces a delay of 5 seconds to retries, which eases those performance issues.

Previously, when a push event had two opposing conditions such that the skipping condition evaluated to False while the completing condition evaluated to True, then the push event didn't complete. With this patch, the push event completes in that case, because the skipping condition is evaluated only when a push event is first picked up. It's not evaluated when the completing condition is executed.

Previously, when an Amend order was submitted with a modify action for a product that was past the PONR, that order was rejected, even if there was no actual change. With this patch, the Amend order is given the "No Change" action and isn't rejected.

Patch 999.11

Discarded items were being considered when identifying the terminal state for an Amend or Cancel order. Doing so created a cyclic dependency. This patch fixes that problem by no longer considering Discarded items in that situation.

Patch 999.10

Heap dump data wasn't being generated when there was an out of memory exception. This patch fixes that issue by by adding support for heap dump generation and storing when out of memory.

This patch introduces a new cancel amend option to change how Order Management handles certain orchestration items when an amended order is cancelled. The default behavior is that running or fatally failed orchestration items are processed before the cancellation plan proceeds. The new option, called Discard Compensated On Cancel, marks those orchestration items as Discarded or Failed Discarded, allowing the cancellation plan to begin right away.

Patch 999.9

Fixed an issue in which the push event trigger was processing payloads even after a shut down was initiated, which resulted in skipping of those payloads.

Patch 999.8

• The processAfter date was not calculating for the compensating orchestration items in the amended order. This has been fixed.

• This patch fixes a security issue by upgrading the library to the latest version of Spring Boot Starter Tomcat.

• In certain cases, the action resolver didn't factor in disconnected assets, so a Move order for account scoped inventory items resulted in an "Add" action instead of "No Change."​ That issue has been resolved, and those Move orders are now given a "No Change" action.

• Fixed an issue related to the performance of processing the order status updates in Order Management Plus. This issue occurred due to frequent pod restarts that were triggered when a "ConcurrentRequests Limit Exceeded" response was received from the Salesforce org. This patch handles that error by requesting order status with appropriate delays.

• In certain cases, where multiple source products decomposed to multiple destination products under a single parent, Order Management Plus was creating duplicate fulfillment request lines (FRLs). That issue has been fixed.

• When an orchestration item was completely deleted from the database, and a state change payload for that item was received, CompleterQueueCleanup failed to to complete. This patch fixes that issue, and cleanup activity is not stalled.

Patch 999.7

Plan View Visualization now includes orders that were rejected because of cyclic dependencies. Orchestration items involved in the cyclic dependency are in red (fatally failed) while the rest of the orchestration items are gray (canceled).

Order submit fallouts now have a 15-character Salesforce ID of the order (rather than an 18-character Salesforce ID).

Patch 999.4

Order Management Plus was unnecessarily sending "Action__c" as part of the ODIN back sync payload, causing the sync to fail. As of this patch, that field is no longer being sent.