Using user exits to extend standard transactions
Sterling™ Order Management System provides the ability to extend or override key business algorithms. This is accomplished through user exits that are invoked when the algorithms are run.
- Override application logic by providing its own logic.
- Extend application logic by providing more inputs to the application algorithm.
For example, if an order is split into multiple shipments, you may need to compute the order price differently for each shipment. In order to change the way the Sterling Order Management System computes order prices, you can override the specific computation or algorithm in the repriceOrder user exit.
Each user exit is a separate Java™ interface. You may choose to implement only those user exits where you want to override or augment the business logic.
com.yantra.ycm.japi.uecom.yantra.ycp.japi.uecom.yantra.ydm.japi.uecom.yantra.yfs.japi.ue
Implementing and deploying user exits
All user exit classes should be deployed as a JAR file that is available in the CLASSPATH of the agent adapter script and in the smcfs.ear file deployed in your application server.
Guidelines for user exits
- User Exits are structured to return specific information and hence their usage must be restricted for such purpose alone.
- From the user exits, you cannot invoke APIs that modify the data. This is to ensure that errors do not occur because of the data that is getting modified in the parent transaction (the transaction that calls the user exit), and the same data getting modified in the user exit custom code. For example, you cannot invoke a changeOrder() API from a user exit that obtains information related to the same order.
However, APIs that do not modify the data (like select APIs) can be invoked in the user exits. For example, you can call getOrderDetails() API from a user exit.