Skip to main content

Getting Started

Using the PEX framework to incorporate external language components into an interoperability production consists of the following steps:

  1. In your favorite IDE, write the business host or adapter in an external language and compile the code.

  2. In the Management Portal, register the new PEX component. An ObjectScript proxy class is created for the PEX component automatically.

  3. If your PEX component is a business service, business operation, or business process, use the standard wizard to add a business host to your production, specifying the ObjectScript proxy class as the class of the business host. If your PEX component is an adapter, modify your business service or business operation to reference the adapter’s proxy class.

PEX Libraries

Each external language has a PEX library that includes superclasses for each type of production component. The available PEX libraries are:

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

Working with PEX Components

A PEX component consists of a remote class written in an external language and an ObjectScript proxy class that the native production uses to work with the remote class. Before adding a custom PEX adapter or business host to a production, it must be registered as a PEX component. Once registered, details about the component are available to users who are building the production. To view and register PEX components, use the Management Portal to navigate to Interoperability > Configure > Production EXtensions Components.

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.

FeedbackOpens in a new tab