System administration components: defining user exit implementations

You can define user exit implementations. User exits are created to enable business logic extensions to the Sterling™ Order Management System transactions.

Within the Sterling Order Management System transactions, code exists to invoke user exits so that you may plugin custom logic. Since these are predefined by Sterling Order Management System, you cannot add or delete user exits. However, you can configure appropriate implementations for a user exit.

User exits are Java™ interfaces which can be implemented for creating custom logic components. Once implemented, they must be configured so that the Sterling Order Management System transactions can invoke them to perform the necessary logic at runtime. This chapter explains how to configure user exit implementations within Sterling Order Management System.

Note: If you do not require the Sterling Order Management System transaction extension, you do not need to implement user exits. If a user exit is not configured, Sterling Order Management System runs its default business logic. User exits are not relevant when writing custom transactions.

User exits and document types

Document types are a mechanism through which you can manage various business documents and their life cycle. Sometimes you need different implementations for a user exit depending on the document type. For example, the YFSRecalculateHeaderTaxUE user exit allows you to compute order header taxes using custom logic. If you want your tax computation logic to differ for Sales Order, Purchase Order, Return, and so forth, you can provide different implementations for the same user exit at the document type level. Notice that not all user exits are document type dependent.

User exits and services

User exits that take XML input and return XML output are service enabled. This means that for these user exits, instead of writing Java implementations, you can simply attach a service built through the service builder. At runtime, instead of invoking the Java class, the Sterling Order Management System transactions invoke the configured service. This allows a mechanism to build user exit logic in a more declarative fashion than programmatic.

Guidelines for usage of user exits

The following guidelines have to be kept in mind when you are using User Exits within the Sterling Order Management System API:

User Exits are structured to return specific information and their usage must be restricted to such purposes.

Inheritance

You can configure inheritance for resources such as user exits (and their events) and templates at the Enterprise level. For example, instead of defining a whole new set of resource configurations, Enterprise "B" may choose to inherit the resource configuration from Enterprise "A".

You can configure inheritance at the Enterprise level for:

. User Exits

. Templates

Inheritance for user exits

You can inherit user exit implementations at the Enterprise level.

If a user exit implementation exists for the Enterprise, the system returns that user exit implementation. But if the user exit implementation is not defined for that Enterprise, the system checks to see if it inherits configuration from some other enterprise and uses the inheritance hierarchy to search for the correct user exit implementation. If no user exit implementation is found, the Hub's implementation of the user exit for that Enterprise is used.

Inheritance for events

You can inherit event implementations at the Enterprise level.

Inheritance for templates

You can inherit the user exit and event templates at the Enterprise level by specifying the resource identifier for an Enterprise. If the resource identifier is not specified, it is obtained through the inheritance hierarchy.