Administration Console

9.2.4.6
- 9.2.5

Back Next

Global Function Contexts

On the Global Functions page, you can add custom function information for any process on the server. These functions are not within the scope of a contribution.

BPEL processes may contain custom functions that are used within XPath or other expression languages. Process Server provides a

FunctionContext

interface for implementation of custom functions. By using the

FunctionContext

interface, new or different functions may be installed and made available to the Process Server XPath (or another) expression writer.

If you already have custom functions implemented with a different interface, such as the jaxen

FunctionContext

interface, you can use them in your BPEL process.

If you have not yet written custom functions, you can download a BPEL process example from the Education Center on
http://www.active-endpoints.com
. The Custom Function sample includes all the necessary source files for using custom function in Process Developer and on the Process Server.

Compiling your Custom Function with Function Context Classpath References

To implement the Java-based

FunctionContext

interface, you'll need the files that are within:

[Process Developer product folder]\developer\plugins\org.activebpel.enginep_[version]\server\shared\lib

You will use

org.activebpel.rt.bpel.function.IAeFunctionContext

contained within

ae_rtbpel.jar

in order to implement the

FunctionContext

interface. If you are implementing exception handling, you'll need

ae_rt.jar

Adding Global Functions to Process Server

You add custom function details to make the functions known to the engine.

You can specify an absolute classpath location for the function or use a system property to indicate a location that any server in a cluster can point to. You define the system property as appropriate for your application server. You'll add the following information to the Add Global Function Details section.

Name—The name of the custom global function. This name appears in the Custom Function list. The name can be any identifier and need not match the name of the function that is actually used. Also there can be more than one function defined in the function context and have the implementation in the same jar. It is not necessary to create different entries addressing each of the functions.

Namespace—Use the namespace identifying the function. The namespace is declared in BPEL processes using the function.

Class—This is the container file that implements the custom function. This must be fully qualified.

Classpath —The location for the custom function folder, zip or jar file. The custom function must be on the same machine as the server. The classpath can be an absolute path. For example:

C:\apache-tomcat-6.0.20\activevos\lib\MyCustomFunction.jar

In addition, it can be a system property. For example, a classpath using a JBoss system property value might look like:

${jboss.home}\MyCustomFunction.jar

For dependent jars, add a semicolon delimited list, such as:

${jboss.home}\MyCustomFunction.jar;${jboss.home}\MyCustomFunction_dependency.jar

After adding this information, press the Add/Update Context
button.

Process Server validates the function details and ensures that a class loader can load the class files.

If an error is reported, ensure that you have a valid class name and classpath location for the custom function on the same machine as the Process Server.

You can delete any function that you no longer need if you delete the associated processes.

Rename Saved Search

Table of Contents

Administration Console

Administration Console

Global Function Contexts

Global Function Contexts