Server Reference Guide : Managing and Monitoring the OpenROAD Server : How You Can Expose Published Application Interfaces
 
Share this page          
How You Can Expose Published Application Interfaces
You can expose an OpenROAD Server application's external interface using a process called MetaGen. This process is driven from the Workbench where the developer decides which 4GL SCPs and user class methods to publish. It exposes the following interface groups:
System SCPs
Include library SCPs that can be called by a client. These perform session creation, destruction, and other functions.
Procedure GSCPs
Include generated SCPs that cover user written 4GL procedures. Automated OSCA error handling, XML_IN/OUT, and container functionality are available to GSCPs.
Other SCPs (that is, not generated)
Include regular user-written 4GL procedures that have been exposed. Automated OSCA error handling, XML_IN/OUT, and container functionality are not available to Other SCPs and must be implemented with user-written code, if required.
Exposed User Classes (GSCPs generated from user class methods)
Include for each user class method exposed, a corresponding GSCP is generated for the client to call. Automated session management, OSCA error handling, XML_IN/OUT, and container functionality are available to these GSCPs.
To expose published application interfaces
Drill down into the Interfaces node in the tree view to view the entire application interface. SCPs, GSCPs, their parameters, and the nested structure of complex parameters (user classes and arrays) appear as shown in the following example:
The details pane shows the contents of the selected node. Sort the lists by clicking the column headers. Clicking again reverses the sort order.
To display meta data in XML
At the top of the details pane, click the Click here for entire Interfacename metadata (XML) header.
The entire meta data interface is displayed in XML format, as shown in the following example:
 
Note:  For all GSCPs, the originating method’s (or procedure’s) parameters appear and additional system generated parameters are added. These are:
b_osca
(Required.) This parameter is an instance of the Object Server Communications Area structure OSCAgl_osca@orgloss.hlp.
 b_so_xml
(Optional.) If passed by the client after the method has executed, it will contain a well formed XML document generated from the method's parameter interface immediately prior to returning. It should be passed by reference.
p_arr_UCXML_Include
(Optional.) This parameter works with b_so_xml. If XML output is required but only a subset of the method's parameter interface is required in the XML output, use this array to describe the parameters you want to include.
p_so_xmlin
(Optional. Not shown in the preceding example.) If passed, this string object must contain an XML document. XML data is copied automatically to the corresponding 4GL parameter where the tag name matches the 4GL parameter name. This occurs prior to executing the 4GL method.
The XML received by p_so_xmlin can be preprocessed before it is converted to 4GL parameters, and the XML generated from the 4GL parameters can be postprocessed before being returned in b_so_xml. For more information about how to drive the automatic XML-to-4GL conversion, see the Server Reference Guide (see page XML and 4GL Data).