About Java Program Objects (JPOs)

JPOs provide the ability to run Java programs natively inside the kernel without creating a separate process and with a true object-oriented integration feel as opposed to working in MQL.

JPOs allow you to write Java programs on top of the ENOVIA Studio Customization Toolkit programming interface and have those programs invoked dynamically.

When running inside the kernel, the programs share the same context and transaction as the thread from which they were launched. In fact, the Java programs are running inside the same Java Virtual Machine (JVM) as the kernel.

Java Program Objects are also tightly integrated with the existing scripting facilities. Developers can seamlessly combine MQL, Tcl, and Java to implement their business model. Tcl will continue to be supported and offers a scripting approach that makes sense in some cases, however the Java language has several advantages:

• Java is compiled, and therefore offers better run-time performance
• Java is object-oriented
• Java is thread safe

Java code must be contained in a class. In general, a single class makes up the code of a JPO. Simply translating Tcl program objects into Java is not the goal as it leads to many small classes, each containing a single method. The very object-oriented nature of Java lends itself to encapsulating multiple methods into a single class. The goal is to encapsulate common code into a single class.

A JPO can be written to provide any logical set of utilities. For example, there might be a JPO that provides access to Administration objects that are not available in the ENOVIA Studio Customization Toolkit. For the most part, a JPO will be associated with a particular Business Type and the name of the JPO should contain the name of the Business Type.

The Java code in a JPO should be thought of as server-side (back-end) implementation code.

A JPO can be written to provide any logical set of utilities. For example, there might be a JPO that provides access to Administration objects that are not available in the ENOVIA Studio Customization Toolkit. In general, a JPO is associated with a particular Business Type. ENOVIA recommends that the name of the JPO contains the name of the Business Type (but this is not required). Access to a JPO should be done through an interface Bean.

The JPO programmer is responsible for manually creating a JPO and writing all of the methods inside it. Keep in mind that JPO code should be considered server-side Java; no Java GUI components should ever be constructed in a JPO.

JPOs are ideally suited for use inside applications resulting in the advantage of moving Java code off the JSPs (away from the View and into the Model, considering the Model View Control design) and executing it on the appropriate application server (back-end) tier for optimum performance.

JavaBeans can be used on the Web server (middle) tier by JSPs as the interface to the JPOs.

The ENOVIA products ship with JPOs defined for most Business Types in the schema. Their style adheres to the guidelines found in this guide. These JPOs can be used as examples when writing your own JPO. Extensions to the ENOVIA products should use inheritance from these JPOs.

Each JPO is shipped as a combination of a base class and a derived class. All out-of-the-box (OOTB) business logic is placed in the base class. The derived class is available for extensions to the business logic. Since the system always refers to the derived class, custom extensions are picked up without needing to change OOTB logic. For example, a Business Type named Project would be represented by the 2 JPOs named emxProjectBase and emxProject (which extends emxProjectBase). Any custom business logic should be placed in the emxProject JPO. This form of application extension is less susceptible to problems associated with installing a new version of the application.

To further exploit the power of inheritance, the ENOVIA Business Process Services ships with 2 JPOs that serve as the base class for all type JPOs (business object and relationship) in the schema. The JPO emxDomainObject should be the base class for each JPO representing a business object type. The JPO emxDomainRelationship should be the base class for each JPO representing a relationship type.

The Runtime Program Environment (RPE) is accessible to JPO methods using the ENOVIA Studio Customization Toolkit MQLCommand object.

The various get and set environment commands can be passed and the results received back. The RPE is not dependable in the thin client architecture of ENOVIA products. The RPE should be avoided in this environment.

You need to write individual Tcl Program objects for each method of a Business Type.

However, these individual Tcl Program objects should just be wrappers that call the appropriate JPO method. Likewise, Tcl Program wrappers should be used on the command bar to call JPO methods.

These Tcl wrappers can use macros that are then passed to the JPO method as arguments. This is necessary since JPOs are compiled and therefore lose any use of macro substitution. The Tcl wrapper gets the appropriate macro values at runtime and passes them along as arguments to the JPO method.

The issue of scalability comes down to the specific schema and functionality of the implementation. An implementation may be able to support 4,000 concurrent users on a certain hardware/software configuration, but on that same configuration they might not be able to support another custom application with 500 concurrent users.

Use of Web Navigator mean that the schema, the triggers, etc. are all custom and scale at a different rate than any other ENOVIA Live Collaboration implementation.

The approach to take is to find out what in the specific application uses a lot of resource and re-architect it to be either more efficient, or offload it to a background process on another server. If 500 users are utilizing 100% of the CPU, then either more CPU is needed or the application needs to be more scalable. Inefficient use of APIs, complex triggers that need to be executed frequently, and inefficient data modeling are common sources of scalability issues. Database tuning including adding additional indices, is an effective technique to improve performance and scalability simultaneously. Code and design review specifically with an eye toward scalability is the recommended approach.

Whenever working with the Java language, establishing the proper CLASSPATH is important for both compiling and running the program. At runtime, the application server needs to know about all necessary .jar files in its implementation of a classpath.

The installation programs for the ENOVIA Live Collaboration Server configure a variable called MX_CLASSPATH that is added to the environment's CLASSPATH to compute it at runtime. For compiling, add MX_CLASSPATH to your environment, ensuring that it includes references to all necessary .jar file. Refer to MX_CLASSPATH in the Studio Modeling Installation Guide for details.

The first step in debugging any Java program is to check that the CLASSPATH used by the server includes all necessary .jar files.