Programs

A program is an object used to execute specific commands.

Programs can be used in these instances:

  • In format definitions for the edit, view, and print commands.
  • As Action, Check, or Override Event Triggers, or as actions or checks in the lifecycle of a policy.
  • To run as methods associated with certain object types.
  • To populate attribute ranges with dynamic values.
  • In expressions used in access filters, where clauses, and configurable tables.

For more information, see MQL Command Reference: program Command.

This page discusses:

Types of Programs

Many programs installed with the Collaboration and Approvals include Java code and are invoked while performing operations with apps. This type of program is defined as Java. The majority of your programs should be Java programs (JPO).

Some programs might execute operating system commands. This type of program is external. Examples are programs such as a word processor or a CAD program which can be specified as the program to be used for the edit, view, and print commands in a format definition.

Other programs might use only MQL/Tcl commands (this technology is older and Java programs written with the Studio Customization Toolkit will perform better, particularly in a Web environment.) For example, a check on a state might verify the existence of an object using an MQL program.

Some programs may require a business object as the context or starting point of the commands. An example of this is a program that connects a business object to another object.

For information on using programs in an implementation, see the Legacy ENOVIA Web Apps Customization Guide. It contains key information including:

  • Compiling programs
  • Extracting and inserting JPO code
  • Passing arguments
  • Java options

Java Program Objects

A Java Program Object (JPO) contains code written in the Java language. 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 developers to write Java programs using the Studio Customization Toolkit programming interface and invoke those programs dynamically.

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

JPOs are also tightly integrated with the scripting facilities of the 3DEXPERIENCE platform. Developers can seamlessly combine MQL, Tcl, and Java to implement their business model. However, while Tcl continues to be supported and offers a scripting approach that can makes sense in some cases, the Java language brings several advantages over Tcl:

  • Java is compiled, and 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 will make up the code of a JPO. However, simply translating Tcl program objects into Java is not the goal. This would lead to many small classes, each containing a single method. The 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 Studio Customization Toolkit. Usually a JPO is associated with a particular Business Type. The name of the JPO should contain the name of the Business Type (but this is certainly not required).

It is the responsibility of the JPO programmer to manually create a JPO and write all of the methods inside the JPO. The JPO code should be considered server-side Java; no Java GUI components should ever be constructed in a JPO.

For more information, see Legacy ENOVIA Web Apps Customization Guide.