APIs

Sterling Selling and Fulfillment Foundation provides an extensive list of APIs that client programs can invoke. Here are some recommendations for you to consider.

API output XML files

The Sterling Selling and Fulfillment Foundation APIs, such as getOrderDetails, return data based on the specification of the following two XMLs files:

The output XML file defines all the possible elements and attributes that the API is capable of returning. The template XML file allows you to specify a subset of the elements and attributes that the API returns.

For performance, especially for high volume APIs, you should optimize the template XML file.

In the template XML, strive not to use the TotalNumberOfRecords attribute. Coding this attribute makes the application issue a separate count query against the database. The count query can be expensive if there is a large number of records that qualify.

List APIs

List APIs allow you to retrieve sets of data from the Sterling Selling and Fulfillment Foundation database. These APIs are typically labeled getXXXList - for example, getItemList, getLocationList, and getOrganizationList. In some cases, the list API could "find" a large number of records which would cause the API to return a very large output XML. If unchecked, the output XML could consume a large portion of the Java™ heap.

Developers can, and should, limit the number of records returned by setting the attribute MaximumRecords in the list XML. For example, the following input XML returns at most 2 records:

   <Item MaximumRecords="2" />
   

You can also enforce a system-wide limit by setting yantra.app.maxrecords (see API control).

User exits and events

APIs give you the ability to add your own custom code in user exits or events at well-defined points in the processing. The user exits and events are defined in the Sterling Selling and Fulfillment Foundation API Javadocs.

When using user exits and events, keep the following in mind:

You need to be aware of whether you are holding record locks when invoking user exits or events, especially exits or events that could take a long time to process. For example, if your transaction is holding YFS_INVENTORY_ITEM locks and your exit takes a minute to process, you could potentially block other inventory processing transactions that requires that lock.

You can find out whether you are holding on to locks during a call out by review VERBOSE traces. Look for any SELECT... FOR UPDATE statements issued prior to the call out.

Calling a user exit while holding on to locks may not be an issue if you are certain the user exit or event completes quickly (e.g., less than 100ms). For example, you may have coded a user exit to publish an ON_SUCCESS message to a message queue. The call out response time is less certain if your exit calls out to an external system. We have seen many cases at customer sites where external systems call outs either failed to return or have taken over two minutes.