This document is deprecated, for more information refer to External object
External Object is a generic name for objects that your application has to interact with but are not managed by your application. These External Objects may be implemented in different languages and or use different protocols as follows:
- Web Services - WSDL (Web Services Description Language)
- Plattform classes
- .Net Assemblies .Net
- Java classes
External objects can be defined in two ways. Using the External Object Editor or using "Inspectors".
When using the External Object Editor you have to provide, depending on your external application, the following items:
- Properties
- Methods
- Mapping to external types

Note: As of Rocha Beta 2, you can define only one mapping for each external data type. In future versions it is expected that you can define one set of mappings for each environment (Java, .Net, etc.).
Using "Inspectors" is usually simpler than manually describing an external object. They inspect the external application for you and create / populate the External Object.
When creating an External Object, you can choose which inspector to use; this defines the external object to import and it is valid for webservices or Platform classes
Import is produced in two steps:
-
Choose the Webservice Description WSDL or Native File .
-
Pressing the Import button the SDT`s and service or classes description are imported.
In the case of Webservices the inspector dialog have two areas. The area having a tree exposes service definitions and the structures that they use. In another area, the information of the selected element of the tree is shown.
Once, for example, a WSDL is selected, the tree has two elements: the first one contains the service definition; the other one, the scheme definition. To select any scheme element, you will be able to see the structure of the XML file.

The object is imported with the web service definition. This object have a user selected name. In addition a SDT by each structure used by the methods is imported. This SDT´s are created with the
In the case of a Native Object the inspector dialog displays a tree structure where the different classes are shown.

In GeneXus, the external objects are used in the same way than SDTs; in other words, you define a variable external object-based, and then use its properties and methods.
Sample .NET Native
- The native classes have to be copied into the Application directory.
- Parameter "no managed" or constructors with parameter nomanaged ("unsafe") are not supported. This means that somethink like the following is not supported
- The consumption of Static Methods is not implemented yet.. It means that is not possible to consume something like this
public static int multiplicar(int a, int b)
{
return a * b;
}
- If the Java Class send an exception like this
public void method(...) throws IOException {
......
throw new IOException(...);
....
}
It is necessary to configure the "Throws Exceptions" Property with the value Yes in order to compile succesfully
In this case an exception like this would be send to the standart output:
Exception in thread "main" java.lang.RuntimeException:
The external object throws an exception.at SdtFactura.init(SdtFactura.java:39)at ausefactura.execute_int(ausefactura.java:60)
If you're using Beta 2 to develop an application that requires service consumption, just create the external objects as previously described. This means that to access the Wsdlinspector from previous versions you now have to create the external object and select the "Use inspector" and "WSDL" options.
To migrate a KB created with version 9.0 or lower, create the external objects, with the same name used to define the data type in GeneXus 9.0, and consolidate the .xpz file. This means that if in GeneXus 9.0 you have defined a variable of Webservice type called "KbName.Aprc01," you need to create an external object in the Rocha version called "KbName_Aprc01" and consume the corresponding Wsdl.
If created with version 9.0, another possibility is to open a copy of the KB (with the kbdata directory) and convert it. We have found some errors in this method that will be solved in coming builds. The error is as follows: Error: Access to the path '<path>' is denied. Knowledgebase Conversion Failed
If the KB was created with Beta 1, you need to import the .xpz file from Beta 1. If you just convert it the Webservices variables will not be assigned and the following specification error will occur:
Variable WSVarName definition is incorrect or not available.