Calling External Components

External classes are used to connect AB Suite methods with functions contained in external components to call subroutines in dynamic link libraries, external batch files, or executable files.

An ExternalClassHost32 COM+ application allows AB Suite 64-bit runtime to call 32-bit external programs, such as Dlls, .NET assemblies, COM components, and EXEs. Refer to the Agile Business Suite Installation and Configuration Guide for more information on ExternalClassHost32.

An AB Suite system on a MCP platform uses the COMTI and J2EE Connector interfaces for programs existing in .NET or J2EE environments. This is achieved by processing external classes or public segment methods defined in the AB Suite system on a MCP platform.

You can map external classes to MCP Libraries and co-routines.

MCP Libraries are programs that are compiled externally and that execute on the caller’s process stack. These can be called by title or by function.
MCP Libraries now support an extended range of library parameters (integer, real, Boolean, ebcdic array, file, and string for type procedures). Accessing libraries from AB Suite is no longer restricted to untyped, single ebcdic array exported procedures.
Access to multiple Connection Libraries (CLs) residing within a single codefile is supported by including the interface name in the Library Name, for example, MyMultilib\Interface1.
Co-routines are C85/Algol/EAE/AB Suite modules that are separately compiled and that execute on their own stack. Calls to such modules are synchronous. Co-routines support the same simple method signature as EAE (glb.param).

Public Segment Methods support a true parameter interface and can be called from a variety of sources (MCP, CE, .NET, and J2EE).

The legacy interfaces of NOF, HUB, Business Integrator, OLTP, GLI, OFFLINE, RAS and USER are also supported.

To call an external component from AB Suite, perform the following:

Create a class and set the IsExternal property to True.
Add a method for each function to be invoked from the external component. Parameters and return variables are limited to the AB Suite Primitive Types and must match those in the external component.
Right-click the external class and select Properties to set the configuration properties of the external class.
In the ExternalClass Property Pages window, set the Component Type property to the type of component you want the class to represent.
Note: You must specify the component type because AB Suite generates different external class wrappers for different component types.
Set the External properties for the selected component type.
Refer to External Configuration Properties of the Builder for more information on setting the connection information for external components.
Refer to General Configuration Properties of the Builder for more information on setting the connection information to call external MCP Libraries and co-routines.
Invoke the external component.
Refer to the following example:
```
returnVariable := Warehouse.GetCarrier(Carrier, PostCode, ProductId)
```
This returns an integer that is tested with the If command.

Notes:

For .NET components

A strong name key should be created for the assembly as part of the external component's project to make it visible to AB Suite's external class wrappers. This key (snKey.snk) is created with the snKey utility and is built with the external project.
After building a .Net component assembly, you must deploy it for Runtime. In most cases, the runtime server is a different machine to the one used to develop the .Net assembly. So you must copy the built assembly to the runtime server and sometimes even register the built assembly. You can copy the built assembly manually, or use Visual Studio's built-in post-build events to automatically copy the built assembly. After you have copied the assembly to the runtime server, for AB Suite Runtime to locate the assembly, you can either add the path of the copied assembly to the PATH environment variable on the machine, or register the assembly in the Global Assembly Cache (GAC) or Regasm.
By default, during a call to an external 64-bit .NET assembly, a new instance is created and the same instance is reused for subsequent calls to the .NET assembly according to the scope of the attribute or variable that instantiates the external class. If the attribute that instantiates the external class is defined as a Segment or Ispec attribute, the external library is loaded on the first call and subsequent calls within a single transaction go to the same instance. Note that there is internal caching of these instances and the next call from a different transaction might or might not go to the same instance. If the external class is instantiated as a method variable, a new instance of the external library is created every time the method is called.
However, you can set the CreateExternalClassInstanceAlways registry key that results in the following behavior; a new instance of the assembly is created when an external method is called and a new instance is created for every subsequent call.
The CreateExternalClassInstanceAlways is of type DWORD and you can set the key at the following locations.
- The registry key for a particular system is stored under the following registry key:
```
\HKEY_LOCAL_MACHINE
 \SOFTWARE
  \Unisys
   \AB Suite
	  \7.0
     \SM Runtime
      \<System Name>
```
and
- The registry key for machine wide settings is stored under the following registry key:
```
\HKEY_LOCAL_MACHINE
 \SOFTWARE
  \Unisys
   \AB Suite
    \7.0
     \SM Runtime
```
Registering the assembly in the GAC or Regasm can make the assembly easily accessible for other programs on the machine and requires simple utilities (such as GACUtil.exe/Regasm.exe, available in the .NET Framework 2.0 SDK), without needing to specifically configure your environment to locate the assembly.