In a previous blog, Finally RPG gets the control it always wanted on IBM i, we looked at some of the benefits of multi-tier architecture provided by Open Access. It's time to revisit the subject in a bit more detail and examine the ways we can leverage these multi-tier benefits with UI metadata definition.
Metadata is information about your I/O fields. It is possible to have metadata within the DDL or your DDS that describes your display file. You can also have metadata that describes elements for a new device or resource your OA handler is connected to.
Depending on your chosen OA implementation, your metadata may be accessed by different processing languages or different tiers. With OA you can entirely control the format, extraction and location of metadata. The Open Access developer has many choices when it comes to encoding metadata: XML is more frequently used to support multiple platforms and multiple use cases while JSON is often used when the consuming client is specifically a web browser.
XML is a cross-platform, industry standard for defining metadata.
- It can be validated against a DTD or be transformed with XSLT.
- It can describe constants or literals in Unicode (DDS-based storage lacks this ability).
- Processing of XML is directly supported by RPG’s XML-INTO and XML-SAX operations codes.
It is the perfect candidate to store and share metadata for any OA implementation and extension.
Figure 1. DDS metadata and new metadata can both be stored in XML.
How to use XML for metadata from DDS and other sources:
Open Access uses the name of the handler for reference and does not require the object file to be present at run-time. There is no need for the metadata to be tied to the object file - you can generate metadata from different sources and store it anywhere.
The User Interface is composed from 2 sources, the data field buffer definition and the metadata definition.
With OA, the metadata is no longer integrated into the 5250 data stream, the OA handler has to get it independently. This independence provides us with a multi-tier environment as now the handler can extrapolate metadata on-the-fly or source it from an external repository (which could be in any format). This is useful when you are developing for modern devices where we can extend the XML with new xml-tags to allow for UI controls like images, links, combo-lists etc..
Data field definition
The data field definition is the buffer, as defined by the RPG compiler, for each record-format. It can be composed of fields and indicators:
- Indicator: Length = 1 , Type = Boolean.
- Field name: Length, Type.
|Note: Open Access can control the I/O buffer by field name or by format name.|
The metadata definition describes I/O fields.
From a DDS perspective it includes:
- Field positioning (row, column and length) - for DSPF and PRTF
- All DDS keywords
From a UI perspective it includes:
- UI attributes: field type and length
- UI properties: background color, border, etc.
There is an Open Access Metadata Open Standard (OAMOS).
Version 1 of the standard was announced at COMMON 2012 by IBM and other members of the OAMOS consortium. Consecutive versions are evaluated by the OAMOS approval college.
The standard includes DDS information and other new UI device or resource metadata.
The core objective of OAMOS is to provide a simple common foundation that can be shared by Open Access implementations. It is designed to reduce lock-in to a specific implementation type and allows developers to mix and match various solutions, which in turn may add value to the project as a whole. It also ensures that each implementation can support a variety of devices, as simply as possible.
The standard makes it easier to work with multiple handlers from different suppliers. Developing or interacting with a handler is made easier as OAMOS provides a transparent and extensible architecture. Another important advantage of the standard is that, while simple to implement, it doesn’t limit solutions to a specific technology such as a printer or Web browser. This allows developers to deal with today’s requirements with the flexibility to adapt to future innovations.
An example of the OAMOS code for a simple subfile-control is shown in Example 1 OAMOS XML sample.
|Note: The Open Access Metadata Open Standard (OAMOS) consists of an XML tagging convention for metadata description.|
Example 1. OAMOS XML sample
<?xml version="1.0" encoding="UTF-8"?>
<fmt name="FMT1CTL" lib="MYLIB" dspf="WRKMOVIE" type="SFLCTL" mode="80" recasc="EC1SFL" CCSID="37" X="1" Y="1" width="80" height="24" strRow="1" endRow="8">
<fmtKwd kwd="SFLCTL" value="EC1SFL" />
<fmtKwd kwd="SFLSIZ" value="0100" />
<fmtKwd kwd="SFLPAG" value="0013" />
<fmtKwd kwd="CF03" value="03" />
<fmtKwd kwd="OVERLAY" />
<fmtKwd cond="92" kwd="SFLDSP" />
<fmtKwd cond="91" kwd="SFLDSPCTL" />
<fmtKwd cond="90" kwd="SFLCLR" />
<fmtKwd cond="89" kwd="SFLEND" />
<fmtKwd kwd="PRINT" />
<fmtKwd kwd="HELP" />
<ind name="*IN03" use="I" />
<ind name="*IN89" use="O" />
<ind name="*IN90" use="O" />
<ind name="*IN91" use="O" />
<ind name="*IN92" use="O" />
<fld type="const" use="O" X="33" Y="1" width="16">
<fldKwd kwd="DFT" value="Work With Movies" />
<fldKwd kwd="COLOR" value="WHT" />
<fld name="DATEFROM" type="L" use="B" X="25" Y="6" width="10">
<fldKwd kwd="DATFMT" value="*DMY" />
<fldKwd kwd="MAPVAL" value="('01/01/40' *BLANK)" />
For more information about the Open Access Metadata Open Standard (OAMOS) see: ibmsystemsmag.com/ibmi/developer/rpg/oa_standard/
For more information about the OAMOS wiki see: IBMiOA.com
The opportunities that RPG OA opens up are numerous, and you can hear more about its potential and future developments in an upcoming webinar Dec 3. I encourage you to register for the opportunity to hear IBM RPG experts, Barbara Morris, Tim Rowe & Trevor Perry explore RPG and its benefits.
IBM i ISV Advisory Council