IBM Support

IBM Sterling Order Management 2022 Peak Readiness - SME Panel Discussion

Webcasts


Abstract

The IBM Sterling Order Management team conducted a panel discussion in preparation for the 2022 Holiday Peak season on the IBM Order Management SaaS platform.

Thursday, July 28, 2022 10:00 AM | 90 Minutes | Eastern Daylight Time (New York, GMT-04:00)

Content

Missed it? No sweat! IBM has you covered. Below is all of the information. Please Share it with your colleagues.
 
As promised for those who were able to attend, the panel discussion replay, the slide deck, the Q&As, and URLs are posted below. We hope you enjoyed the technical discussion we had and were able to generate a full checklist to ensure you are prepared for the 2022 Holiday Season.

Speakers
Chris Burgess – Manager, Americas & AP Support Experience team ​
Mike Callaghan – Program Director, WW Supply Chain Support​
Aparna Subramanian – Technical Lead / Cloud Support Architect​, OMS Support
Shoeb Bihari –Technical Lead / SRE Advisor​, OMS Support
Senthil Ponnusamy – Monitoring Squad Leader​
Paresh Vinaykya – Executive Technical Account Manager​, Expertise Connect
​Amar Jyothi Annamalai – Performance Architect, Inventory Visibility SME​
Bobby Thomas – Performance Architect, OMS Engineering ​
Vishal Arora – Advisory Software Engineer​, OMS Engineering
Vijay Gosavi – Payments SME​, OMS Engineering

​

The IBM Order Management Support and Development team discussed some of the key configurations, features and best practices from past holiday retrospect to help with peak holiday season traffic on the Order Management on Cloud platform.  IBM discussed the key topics such as:
 
  • Performance tips around Payment Collection/Execution agents
  • Common reasons for YFS_ORDER_HEADER contention
  • Web Store performance and best practices
  • Inventory sync/load with GIV
  • Inventory Visibility APIs and best practices
A recording of the session is available here. 
Q&A
Q: With regard to payment authorization, how do we fix the issues when there is a mismatch between order total amount and authorized amount? 
Also, if manual refund is already done by financial team, then how to stop double refund?

A: In ideal cases, the payment collection opens up authorizations based on order total. A mismatch will need detailed analysis, please open a support case to review the scenario in question. With regard to double refund, you can look into using the API - recordExternalCharges to record the payments manually. Additionally, OMPConfirmRefundDistributionUE can also be used to determine the amount to be refunded.
Q: How can we cleanup the orders having large number of charge transactions (YFS_CHARGE_TRANSACTIONS) as manually recording using API would not work as expected due to large number of records (>10K). Deleting redundant records from DB? Or do you have any other suggestions?
A: If you have case where there are excessive charge transaction, then log a support case to evaluate the situation. 

Q: How to reach Holiday Readiness Team, exclusively to fix peak issues is it through PMR or through our CSM?
A: Both, open a PMR (case) and articulate the business impact, but if it will have potential peak risk, please do inform your CSM also so we can ensure it is prioritized accordingly
Q: With regard to API input timeout properties, what is the out of box timeout value for APIs? Also, what is maximum timeout value we can set if needed to increase?  Is the QueryTimeout in seconds? How to set timeout for getOrderDetails API ?
A: This property accepts timeout value in seconds, and OOB UI request timeout by default is set to 120 seconds (2 minutes).  For web requests (REST API), request timeout of 3 to 5 seconds would be ideal, for asynchronous workload you can set it to 2 to 5 minutes. 

You can add individual query timeouts for APIs. To do this, specify the query timeout (QueryTimeout) value in seconds along with TimeoutLockedUpdates for the API in the API's input XML. Same properties can be used if you are making call via extended mashup. 
Q: Is there any proactive indexing and optimizations done by product team for SaaS PROD environments for Peak interval?
A: Ideally, poor performing queries must be identified during performance/load test in PreProduction environment. Also, any index must be rolled out via entity extension.  Additionally, we do have proactive alerts on slow/lock-wait queries running on production database server impacting resource, and will create proactive case to notify you. 
Q: Is there any way to get the DB contention details with Query Client ? What's the best way to find the services/api which are causing the long running queries from SST?

A: At present we have long running queries, and queries in lock-wait dashboard widgets in Self-Serve Tool under Database Metric dashboard. However, it doesn't provide details around the API or Service.  You can further narrow down the API/Service by looking at the YFS_STATISTICS_DETAIL table, furthermore you can trace (SQLDEBUG) the API to get more details. 
Q: What is your recommendation in directly making a connection call in the custom code, there are some requirements where there is no direct API to access those columns, or even if we want faster result set?
A: Direct DB call from custom code are not permitted, it is against the OMoC best practice. If you have requirement to query and unable to identify the OOB API to achieve it then log a support case to further discuss the requirements. You can also raise Aha request or new API or enhancement for existing API. 
Q: We are facing long run time while iterating through the shipments retrieved from getShipmentListForOrder api cause it fetches all the cancelled, TO and RO shipments as well. Is there a way to fetch only SO shipments? (Passing document type didn't help).
A: Filtering should apply if you are passing DocumentType attribute; however, if you are not seeing the expected result, then open a support case with IBM for further assistance.
Q: We do get an alert via email when the agents, integration server, or app-servers are down, specifically when there is DB contention, is it not better to raise an auto alert? Understanding DB contention from SST is too difficult after the issue occurred. 
A: Upon receiving alert IBM support performance initial triage and raises a proactive case. For notification and proactive support case flow, please refer to Slide 17, Proactive Support Model. For direct alert use case please raise Aha request for this enhancement.  
Q: Can we have an option to have patch deployment in SST rather than waiting for 2:30 - 3 hours for a full deployment ? We might have changes in only one custom class. 
A: Patching is not available. Ideally, the deployment should not take more than 1 hour. If you are seeing longer deployment times then please raise a support case with Self-Serve process Id. Based on our research, we have seen that during the deployment the majority of time is spent on table REORG (depending on the size). As part applying DDLs in entity deployment generated by DB Verify in DB2 database, every alter DDL is accompanied with a REORG on the table every time. However, most table alters do not require reorg, as such in OMoC recent release we have refactored the db verify logic to limit the REORG execution to only when it's necessary based on the schema change. This has reduced deployment time significantly.    
Q: What are the inventory considerations or best practices when using IV, we don't have inventory loaded in OMS DB, it all gets recorded in IV?
A: Please refer to Inventory Visibility best practices.   
Q: Can you please elaborate what is  'Hot SKU Feature'?
A: Hot SKU is a feature that increases performance by lowering lock contention on the YFS_INVENTORY_ITEM table. The Hot SKU feature is enabled by default for the IBM® Sterling Order Management on cloud. For additional details, refer to below reference material.
 
Q: How does inventory purge works in case of IV?
A: You can set to filterZeroValues exclude 0 quantity records from API output. Purging IV data is handled by IBM. 
Q: Per java docs, loadInventoryMismatch does not invoke any UE, but we have implemented YCMGetItemDetailsUE which is getting invoked when loadInventoryMismatch is invoked. Is this something expected? 
A:
Q: IV has POST and PUT call to take inventory, one of them take absolute value and the other takes changeQuantity; however, currently IV doesn't take negative value of inventory picture, like -10. Some of the clients have requirements to send a negative picture of inventory?

A: Please raise Aha enhancement request for this requirement. 
Q: We are running OMoC, can we use DB Query Client to query IV database?
A: Only OMoC DB can be queried via DB query tool. For IV, you will have to use the APIs. 
Additionally, Order Hub UI allows you to review audits, availability, etc.  You can also trigger and consume IV events, and populate local DB for querying and analytic purpose.  
Q: What is the IBM recommendation for inventory sync (i.e. load, sync and adjust) of 2.5M items, across 600 ship nodes with batch size of 1000? What should be the recommendation with regard to JVM configuration,  number of instances,  number of threads, etc?
A: Ideally you want to limit the workload based on items sold (sales catalog), 5M item-node combination on daily basis would be ideal with GIV.  As far as JVM configurations are concerned, single JVM with 4 number of threads, and 2GB memory ( balance server profile) should yield throughput of 1 million item-node per hour.  Furthermore, you can scale the # JVMs to achieve expected throughput. 
Note: Above numbers are based on OOB configuration and data set, throughput 

With IV,  it is recommended to send messages with a batch of 100 items and payload size <500 KB.
Q: Earlier inventory purge was not considering retention days to purge out 0 qty records from supply and demand table and were being purged always in the next run. With one of the update from IBM last year, the agent started considering retention days and was not purging 0 qty records until retention days is elapsed. This is actually causing performance issues during peak as there's a lot of 0 inventory updates increasing the table size and we also stop purge agents based on IBM advise. What would be the best way to handle above case when the retention days for inventory purge is a common one for all the tables and this applies to 0 qty records as well?
A: Earlier fix was provided in 21.1 for inventory purge to consider the retention period set. 
  • 580763: Inventory Purge is deleting Demand and Supply without considering the retention days
If you do not want to consider the retention days, it can be set to 0. This will delete the below data (with other criteria being met):
  • Supply record has 0 quantity and MODIFYTS date is before the system date 
  • Demand record has 0 quantity and demand ship date is earlier than the system date
  • Inventory reservation record has 0 quantity or ship date is earlier than the system date
Q: As to the "Token Generation" topic, would you please provide some documentation on how to use JVM cache? 
A: Recommended approach is to hold the token in JVM cache as a static variable (instead of database) and let it live and reuse this across all calls in that JVM till the JVM is alive, or token expires. We are working towards updating the documentation to reflect this.
Q: What are the maximum number of columns that can be added/extended to an OOB table by not degrading performance?
A: It's not the number of column which degrades the performance, rather it is number of indices. Higher the number of columns means addition indices. Index can impact performance of the inserts. As far as exact number is concerned, it would depend on the table usage and type of column, the CLOB/BLOD data types will have higher impact.  As a best practice you can consider creating hang-off table with adequate purge/maintenance/testing strategy. For details, refer to: Creating (and purging) custom and hang-off tables
Q: What are the best practices for IV inventory sync? especially with Hot SKU? Do you have similar presentation what you had in the previous slide for inventory sync in OMS with Hot SKU enabled?
A: With regard to inventory synchronizing on IV, you can refer to use case documented here. In terms of performance, follow the API best practice guidance documented here. 

As far Hot SKU is concerned, the concept is applicable to IV as well; however, there are no performance challenges (i.e db contention) due to underlying database technology used by Inventory Visibility.  With IV, Hot SKU properties and logic we have in OMS is redundant.  If you are using GIV, then please please refer to following documents for additional information: 
Q: Can we have more use cases about inventory velocity implementation?
A: Yes, we will try to include this topic as part of upcoming Webcast. 
Q: Can you please explain what happens when IBA and Inventory Sync runs at same time?

A: IBA is not expected to run during the peak (or peak hours). You may observe slowness in order processing as inventory item and demands will be locked. For details refer to IBA locking.  In terms of functionality, both are independent process, IBA is triggered at an interval generally once in 24 hours and can potentially start after inventory sync. Even if agent is triggered in 5 mins it will not mean same item-node combination is being optimized again. It's driven by configuration rules. If you are running both in parallel then possibility is for that for some items supply may not have been updated but IBA has optimized and made updates already.  Next run for that item-node will be able to correct it.

 

Presentation

[{"Type":"MASTER","Line of Business":{"code":"LOB59","label":"Sustainability Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS6PEW","label":"IBM Sterling Order Management"},"ARM Category":[{"code":"a8m50000000CbuEAAS","label":"Archive (DO NOT USE)->Sterling Order Management System"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Product Synonym

oms, omoc, sterling, order management, Inventory Visibility, holiday readiness, 2022, panel discussion

Document Information

Modified date:
03 August 2022

UID

ibm16609032

Page Feedback