EnterpriseOne Java Application Logic

EnterpriseOne application logic can take any of three forms:

• Business functions - Implemented in C and runs on the enterprise server. This form includes generated C business functions such as those based on Named Event Rules (NER) and Table Event Rules (TER).



• Event rules - Interpreted at runtime by the presentation server. These require that corresponding Java serialized objects be generated, either before running or on demand.



• Java business functions - Implemented in Java and runs on the presentation server. This option is not currently available for mass application development, but rather exists primarily to optimize performance of table triggers. A select group of business functions are dually implemented in C and Java, chosen for the frequency at which they are called and the unlikelihood that they will change or need customization.

The ApplicationLogic_JAR.jar file contains the small set of Java business functions. This document describes the structure of ApplicationLogic_JAR.jar file and provides instructions for configuring and customizing Java application logic.

Contents

The ApplicationLogic_JAR.jar file's contents include the following artifacts:

Configuration

There are two configuration files that affect what application logic form runs for a particular business function:

• LocalLogicCatalog.xml - Designates specific business functions to run locally, that is, within the runtime context of the presentation server.



• BusinessMethodCatalog.xml - Maps business function names to Java class names.

The presentation server loads LocalLogicCatalog.xml using the Java class path. Normally, this file is located in the WEB-INF folder where the WebClient.war web application is deployed.

LocalLogicCatalog.xml contains an entry for each business function that the EnterpriseOne development team has certified to run locally on the presentation server. These business functions are selected primarily to optimize the performance of frequently called table triggers and typically come in two varieties. First there are business functions written using Table Event Rules (TER) that are traditionally generated into C business functions that run on the enterprise server. Designating these to run locally tells the presentation server to interpret them locally rather than invoking their corresponding remote implementation. The second variety are business functions originally written in C but also have a Java implementation that lives in ApplicationLogic_JAR.jar.

Each entry in LocalLogicCatalog.xml is defined using the following form:

	<business-logic
		module="B0000095"
		function="FormatCompany"
		run-local="true"/>

If analysis has determined that a business function described in LocalLogicCatalog.xml will perform better as a remote call to the enterprise server, change the run-local attribute to "false" and restart the presentation server.

The presentation server also loads BusinessMethodCatalog.xml using the Java class path. This file is usually deployed as part of ApplicationLogic_JAR.jar.

BusinessMethodCatalog.xml contains an entry for every business function for which a corresponding Java implementation exists. Each entry in this file is defined using the following form:

	<business-method
		module="B0000095"
		methodName="FormatCompany"
		implClassName="com.peoplesoft.e1.bsfn.b0000095.FormatCompany"/>

If you extend or re-implement the Java implementation for a business function, change the implClassName attribute to refer to the qualified class name for the new implementation. The implementation class must extend com.peoplesoft.e1.appsdk.bsfn.BusinessFunction.

Customization

Most of the logic that ApplicationLogic_JAR.jar contains implements granular, low-maintenance business functions that table triggers invoke. Consequently, it rarely requires customization. If you have customized the corresponding C implementations for any of these business functions, it is highly recommended that you change LocalLogicCatalog.xml to redirect the presentation server to call them remotely. In the event that you absolutely need to extend or change one of the Java business functions that ApplicationLogic_JAR.jar contains, follow the instructions in this section.

1. Unzip ApplicationLogicSource.zip - This file is delivered in ApplicationLogic_JAR.jar and contains the artifacts that you need to extend or change Java application logic. Specifically, these artifacts are:
   
   

   Artifact	Description	Location
   readme.html	This document; describes the structure of ApplicationLogic_JAR.jar and provides instructions for configuring and customizing Java application logic.	/doc
   index.html	Javadoc for application APIs that Java business logic can invoke	/javadoc
   Java source files	Java business functions and supporting classes	/src
   build.bat	A batch file that builds ApplicationLogic_JAR.jar	/

   
   
2. Edit application logic source code - With each of the following options, you can edit the Java code with any integrated development environment or code editor. Reference the application API Javadoc for information about the APIs that Java application logic can call. Choose the option that best suits your customization strategy:



• Change Java business function source code in place - Make sure to create a copy of the original reference source file with an extension other than .java to prevent the compiler from processing it.


OR


• Extend a Java business function class - Create a new class, either in the same package or your own, that extends one of the original reference Java business function classes. This helps to reuse the reference implementation without duplicating it. Override the executeBsfn method and invoke the superclass's executeBsfn method in turn. Add your custom logic before and/or after the call to the superclass.




Here is an example:

public class MyConvertDescriptiontoAN8 extends ConvertDescriptiontoAN8
{
    public void executeBsfn(BsfnRequest request, BsfnResponse response)
        throws BusinessMethodException
    {
    	// Invoke the superclass application logic.
    	super.executeBsfn(request, response);
    	
    	// Implement additional application logic here.  This 
    	// can come before AND/OR after invoking the superclass 
    	// logic.
    }
}
			

OR


• Replace a Java business function class altogether - Create a new class, either in the same package or your own, that extends com.peoplesoft.e1.appsdk.bsfn.BusinessFunction. Your class must implement both the executeBsfn and getDataStructureFactory methods. executeBsfn houses your application logic and normally begins by getting the data structure object from the request. getDataStructureFactory returns a factory that creates the appropriate type of data structure instances. You will normally utilize an existing data structure class from the com.peoplesoft.e1.datastructures package. Refer to the Javadoc for the application APIs for details.




Here is an example:

public class MyConvertDescriptiontoAN8 extends BusinessFunction
{
    public void executeBsfn(BsfnRequest request, BsfnResponse response)
        throws BusinessMethodException
    {
        D03B0108 bsfnData = (D03B0108)request.getDataStructure();

        // Implement application logic here.
    }

    public DataObjectFactory getDataStructureFactory()
    {
        return D03B0108Factory.getInstance();
    }
}
			

In either of the cases where you create a new class, whether you extend another business function class or not, you must update the appropriate BusinessMethodCatalog.xml entry accordingly. For example:

	<business-method
		module="D03B0108"
		methodName="ConvertDescriptiontoAN8"
		implClassName="mypackage.MyConvertDescriptiontoAN8"/>
	

If you neglect this step, then the presentation server will not invoke your customized implementation.

3. Build ApplicationLogic_JAR.jar - build.bat is a Windows batch file that builds ApplicationLogic_JAR.jar in the current working directory. The batch file defines the following environment variables. Replace these values to match your environment before building.




Environment Variable	Description
JAVA_HOME	The directory where your Java installation is located. This build script uses this for compiling and creating the jar file. It must be Java 2 Standard Edition 1.3 or later.
E1_JARS	The directory where the EnterpriseOne Jars are located. This typically refers to the WebClient.war's WEB-INF/lib directory.




This batch file invokes javac (the Java compiler) and jar (the Jar tool). If you prefer another build process or technology, or are working in a non-Windows environment, create an analogous script.

4. Deploy ApplicationLogic_JAR.jar - Save a copy of the original reference ApplicationLogic_JAR.jar to ensure that you have a backup. Copy the new ApplicationLogic_JAR.jar, with your customizations, to your WebClient.war's WEB-INF/lib directory. If you have configured cloning, clustering, or multiple ports, ensure that the copy goes into each WebClient.war instance's WEB-INF/lib directory.