Skip to main content

Getting Started

Implementing external language components into an interoperability production using PEX consists of three basic steps:

  1. In you favorite IDE, write the business host or adapter in a PEX-suppored external language and compile the code.

  2. In the Management Portal, add a built-in PEX component that points to the custom class that you just compiled. This built-in PEX components acts as a proxy between the external language class and the rest of the production. For example, you add EnsLib.PEX.BusinessService as a business service in the production when you have written a custom business service in an external language.

  3. From the Management Portal or InterSystems Terminal, manually start the external server for your language. This external server is commonly referred to as a gateway.

PEX Libraries

Each external language has a PEX library that includes superclasses for each type of production component. Implementing a business host or adapter begins by creating the appropriate subclass and overriding its methods. For example, the PEX Java library contains a class com.intersystems.enslib.pex.BusinessOperation that is the superclass for business operations. The available PEX libraries are:

External Language PEX Library
Java com.intersystems.enslib.pex
.NET InterSystems.EnsLib.PEX

Environmental Considerations

You can use InterSystems IRIS Interoperability only within an interoperability-enabled namespace that has a specific web application. When you create classes, you should avoid using reserved package names. The following subsections give the details.

Production-enabled Namespaces

An interoperability-enabled namespace is a namespace that has global mappings, routine mappings, and package mappings that make the classes, data, and menus that support productions available to it. For general information on mappings, see “Configuring Namespaces.” (You can use the information in that section to see the actual mappings in any interoperability-enabled namespace; the details may vary from release to release, but no work is necessary on your part.)

The system-provided namespaces that are created when you install InterSystems IRIS are not interoperability-enabled, except, on the community edition, the USER namespace is an interoperability-enabled namespace. Any new namespace that you create is by default interoperability-enabled. If you clear the Enable namespace for interoperability productions check box when creating a namespace, InterSystems IRIS creates the namespace with productions disabled.

Important:

All system-provided namespaces are overwritten upon reinstallation or upgrade. For this reason, InterSystems recommends that customers always work in a new namespace that you create. For information on creating a new namespace, see “Configuring Data.”

Web Application Requirement

Also, you can use a production in a namespace only if that namespace has an associated web application that is named /csp/namespace, where namespace is the namespace name. (This is the default web application name for a namespace.) For information on defining web applications, see Applications.

Reserved Package Names

In any interoperability-enabled namespace, avoid using the following package names: Ens, EnsLib, EnsPortal, or CSPX. These packages are completely replaced during the upgrade process. If you define classes in these packages, you would need to export the classes before upgrading and then import them after upgrading.

Also, InterSystems recommends that you avoid using any package names that start with Ens (case-sensitive). There are two reasons for this recommendation:

  • When you compile classes in packages with names that start with Ens, the compiler writes the generated routines into the ENSLIB system database. (The compiler does this because all routines with names that start with Ens are mapped to that database.) This means that when you upgrade the instance, thus replacing the ENSLIB database, the upgrade removes the generated routines, leaving only the class definitions. At this point, in order to use the classes, it is necessary to recompile them.

    In contrast, when you upgrade the instance, it is not necessary to recompile classes in packages with names that do not start with Ens.

  • If you define classes in packages with names that start with Ens, they are available in all interoperability-enabled namespaces, which may or may not be desirable. One consequence is that it is not possible to have two classes with the same name and different contents in different interoperability-enabled namespaces, if the package name starts with Ens.

Feedback