OpenEdge developers have the choice of two approaches for creating an invocation file for ABL procedures and functions:
Declarative — Capture information about publicly exposable procedures in the source code through the use of annotations
Non-declarative —Capture information about publicly exposable procedures through the use of a tool such as ProxyGen
The declarative approach is recommended to OpenEdge developers as a best practice, entering relevant information for making a procedure, function or external procedure publicly exposable when the source code is written. This information is then stored with the source code, and during the build process captured as part of the r-code. In cases where the developer does not want to capture information about publicly exposable procedures with the source code, the non-declarative approach is supported.
Starting with OpenEdge Release 10.1C01the ability, at development time, to drag and drop ABL procedure files directly into a Sonic ESB itinerary is supported. Dragging ABL procedure files directly into a Sonic ESB itinerary eliminates the need to create and import a .esboe file. If your source code is not already annotated with ESB annotations when you do the drag and drop, a wizard walks you through the steps required to add the necessary Native Invocation annotations.
The creation of an ESB itinerary based on .esboe files remains fully supported. The following figure graphically depicts the creation of an invocation .esboe file, following the declarative or non-declarative approach.
Figure 3. Development flow: ABL source to ESB itinerary
Declarative — Capture information about publicly exposable procedures in the source code through the use of annotations
