This section provides a brief overview of some basic elements of the Infranet application that affect the design and implementation of Portal Infranet application-specific business objects. Infranet defines four main programming elements that are used to define, extend, or access functionality in the system. In order to design business objects for Portal, you must be familiar with the following elements. They are briefly described in the sections that follow.
In Infranet, storable classes contain fields that store information about a class. Standard storable classes include account, service, bills, invoices, and other classes that are predefined by Infranet. To extend Infranet functionality, you can create new storable classes or create subsets of existing classes.
Storable classes do not contain actual data; they are object specifications, much as a WebSphere Business Integration Adapter business object definition defines a business object structure but does not contain data. Storable classes include a number of fields, which can be simple fields (for example, an integer or string field), arrays, or substructures.
When a storable class has been instantiated and includes actual data values, it becomes a storable object. Each storable object is identified by a unique Portal Object ID, or POID. The POID contains the database number, the name of the storable class, the instance number of the storable object, and the object revision number.
The distinction between a storable class and storable object is illustrated in Figure 4.
Figure 4. Infranet
storable class and storable object
A storable class can define inherited and extended functionality for the class. For example, the /account/email storable class contains all the information in the account class with additional information that applies specifically to the email extended class. Therefore, the /account/email storable class becomes a subclass of /account as shown in Figure 5.
Figure 5. Extending the /account storable class
Storable objects are manipulated using Infranet application programs, scripts, and tools, or any custom programs and processes. Regardless of their type, all client programs operate on storable objects using the PCM API and programming libraries. Storable objects are manipulated by opcodes, which are routines containing lists of fields that operate on storable objects.
Fields are the simplest data value in Infranet. Each field name in the system has a unique ID, name, type, and definition. Field names are shared and used in many different classes and opcode definitions.
There is a basic set of field types in the system that can be used to create new fields. Table 5 lists the field types. The first six types correspond to data types in programming languages such as C. The others hold more complex data and can point to C structures as their value. Arrays and substructs hold pointers to other lists of fields.
Table 5. Infranet field and data types
Field type | Data type |
---|---|
PIN_FLDT_INT | Signed integer |
PIN_FLDT_UINT | Unsigned integer |
PIN_FLDT_ENUM | Enumerated integer |
PIN_FLDT_NUM | Floating point number |
PIN_FLDT_TSTAMP | Time stamp |
PIN_FLDT_STR | Character string |
PIN_FLDT_BINSTR | Binary string |
PIN_FLDT_BUF | Arbitrary-sized buffer of data |
PIN_FLDT_POID | Portal Object ID |
PIN_FLDT_ARRAY | Array |
PIN_FLDT_SUBSTRUCT | Substructure |
Field lists (flists) are fundamental data structures used in Infranet programming APIs. Flists are containers holding pairs of data fields and values, and in some cases, other flists. Flists can represent floating point calculations, buffers, or large pieces of data that do not fit in memory. Flists pass information between storable objects and the routines or programs that manipulate the storable objects.
A storable object (for example, in an /account storable class) makes up an flist (or part of an flist) that uses the storable class specification. The flist is a list of fields, each with its own attributes, permissions, and data values. Together, these fields define the functionality of the storable object, as shown in Figure 6.
Flists can contain multiple storable objects. The flist structure ensures that the information is passed from the application to the correct storable object.
Figure 6. Storable object and flist
An application uses Infranet system opcodes to carry out operations on storable objects and the fields within them. There are several sets of opcodes, which are grouped into the following functional categories: Base, Customer facilities module (FM), Activity FM, Billing FM, Terminal FM, and Email FM.
Base operations on objects include creation, deletion, writing, reading, and searching. All other opcodes implement business-level (higher-level) semantics, such as logging activities, billing an account for the purchase of a product, checking credit card information, changing a name and address, verifying a password, or recording accounting data. These higher-level opcodes are implemented in facilities modules, where base opcodes are implemented directly by the Storage Manager (SM). The higher-level opcodes are translated by facilities module routines in the Communication Managers to varying numbers of base opcodes and then passed on to Storage Managers.
Every system opcode has an associated input and output flist. A client application determines what is an interesting event, calls the Infranet system with the appropriate opcode and corresponding flist, and handles the return flist and error buffer.