A time-triggered transaction, or agent, is a program that performs a variety of individual functions, automatically and at specific time intervals. It is not triggered by conditions, events, or user input.

There are three types of time-triggered transactions:

  • Business process transactions – responsible for processing day-to-day transactions
  • Monitors – watch and send alerts for processing delays and exceptions
  • Purges – clear out data that may be discarded after having been processed

You can extend the transactions provided by the application by using one of the following mechanisms:

Using user exits to extend standard transactions

Sterling Business Center provides the ability to extend or override key business algorithms. This is accomplished through user exits that are invoked when the algorithms are run.

A typical user exit can:

  • 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 Business Center 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.

Note: When the API or time-triggered transaction is executing the default algorithm, the user exit is called. If your implementation of the function throws an exception, the current transaction is rolled back.

For detailed descriptions of each user exit, see the following Javadocs packages:

  • com.yantra.ycm.japi.ue
  • com.yantra.ycp.japi.ue
  • com.yantra.ydm.japi.ue
  • com.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 .ear file deployed in your application server.

Guidelines for user exits

The following guidelines have to be kept in mind when you are using User Exits within the application API:

  • 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.

Using Variables for dynamic configuration

You can dynamically configure certain properties belonging to actions, agents and services configuration to cut back on your implementation time.

For example, you can provide a dynamic way of configuring network properties such as provider URLs, E-mail server, and Sender addresses. These properties can be configured as variables in one place and can be resolved at runtime when these properties are being used.

You can provide variables in place of file or directory names wherever a file name or path can be entered in the . This variable substitution is based on an entry in the <runtime_sandbox>/properties/customer_overrides.properties file and is resolved during runtime.

You can use variable names in the following components of the :

  • Service Definition Framework
    • All transport types such as JMS queue name, JMS topic name, Initial Context Factory, Connection Factory and Provider URL. File Sender and Receiver, FTP source and destination for sender and receiver directories and HTTP and Webservice transport types.
    • In the e-mail component, where you can specify, the email server, subject, listener port, and From addresses. The dynamic configuration can also be used for specifying the email protocol.
    • Actions – In call HTTP extension and Execute Program.
    • Agent criteria details – JMS Queue Name, Initial Context Factory, Connection Factory and Provider URL.
  • Printer Devices, Print Documents, and Print Components
  • Purge Criteria’s log file name
  • In the System Management console:
    • You can use variables to specify installation rules such as e-mail server name, server IP address, server listener port, and e-mail protocol.
    • You can provide variables for the JMS monitoring configuration fields, which include: WebSphere® Channel name, host name, port number and queue manager name.

For the fields identified above, you can configure the values as yfs.VARIABLE_NAME in the /properties/customer_overrides.properties file. It is stored in the database as is and at runtime when the variables are used, a lookup is performed in the customer_overrides.properties file to decipher the value. Since the values for these variables are fetched from the customer_overrides.properties file, they are specific to a particular JVM.

Note: The value of this variable cannot be seen in the health monitor agent details, since the value depends on the JVM on which it is deployed. You have to click on the server details of the monitor agent to view the value of the variable.

For example, if you want to set the File IO Receiver’s directory structure to a common variable (such as ${ffbase}) , then the incoming directory should be set to:

${ffbase}/incoming

The value for the variable ${ffbase} that you defined in the must be defined in the customer_overrides.properties file with a prefix of yfs as:

  yfs.ffbase=C:/FileIODir/Receiver

This ${ffbase}/incoming value is stored in the database, and when processing the file adapter, the variable is resolved to C:/FileIODir/Receiver/incoming.

The following conditions are assumed for the usage of this variable:

  • All the variables when referenced must be in the following format:
    ${variable_name}
  • All variables should be properly formed. If a variable is not found, no substitution takes place.
  • Variables must not contain the ‘}’ character.
  • Variables must not begin or end with a whitespace character.
  • Templates do not support variables for filenames since they are always resolved within the classpath.

Join The Discussion

Your email address will not be published. Required fields are marked *