White Paper /
Callable Global Logics
CONTENTS
Overview 3
Business Rule Abstraction 3
Application Integration 3
Interface Binding 3
Invoking with Component Enabler 4
Migrating Performable Global Logics 5
Sample 5
Description 5
Description of Steps 5
Overview
The purpose of this document is to provide an introduction to Callable Global Logics (Callable GLGs) and show the importance they play in delivering faster application integration.
A simple example of a Callable GLG is provided at the end of this paper. Use it to get you started on defining a library of Callable GLGs within your Enterprise Application Environment (EAE).
Business Rule Abstraction
To maximize the benefits of a Callable GLG, view it as a mechanism for providing a higher-level of abstraction for defining units of work within a transaction.
A standard Performable GLG is merely a subroutine shared between Ispecs, executed as a part of the LINC-cycle. By defining a global logic as callable you create an object that has the potential to orchestrate every aspect of the transaction when invoked from a routine external to the Enterprise Application Environment.
Callable GLGs, however, have effectively removed the LINC-cycle from the equation. They can be written to perform the processing of the Business Rules, while maintaining the integrity of the underlying data within the Enterprise Application Environment.
Application Integration
Current interfaces such as NOF only provide a low level interface to Ispecs. Eventually the units of work, which define important Business Rules, will become entrenched and rewritten in the applications accessing the Enterprise Application Environment. Callable GLGs can encapsulate these Business Rules and provide a richer and simpler interface to the Enterprise Application Environment.
Interface Binding
To be independent of the LINC-cycle, a Callable Global Logic is fully self contained. Data is exchanged through a parameter interface, similar to the Report Parameter. The parameters of a Callable Global Logic are defined using specialized Setup Data Items that are organized into a Group. This group forms the interface to the Callable Global Logic, which is inserted into the Setup Data Item lists of EAE objects referencing that Callable Global Logic.
An integral part of the specialization is the direction of data exchange. The definition is semantic only and does not restrict access to any parameter. For instance, the user can modify a usage input parameter (I) within a Callable GLG. A good example is a counter passed as an input parameter, it can be decremented within the Callable GLG without affecting the original value as seen by the caller.
Note that bi-directional parameter usage’s (IO) implement pass-by-reference, whereas unidirectional are pass-by-value. This should help to explain why, in the previous example, the original value was retained by the caller.
Invoking with Component Enabler
With Component Enabler Subclassing and Callable GLGs, we have the ideal opportunity to create Components with our EAE systems.
For example:
§ Create a Callable GLG to provide the business logic you wish to present as a component
§ Insert this into a new memo Ispec
§ Paint appropriate usage input fields onto the Ispec to transfer data
§ Include logic to move these screen fields to the Setup Data Items of the parameter interface
§ Finally return the results by moving output parameter items to the screen fields.
With Component Enabler:
§ Subclass the LINCEnvironment class
§ Provide your own method and properties that will connect
§ Logon
§ Get the fireup Ispec
§ Get your memo Ispec
§ Fill in the fields
§ Transmit it to the EAE system
§ Finally return the values.
With your client, you can now simply create the object, set the properties with the data to use for the call, invoke the method and when it returns you can access the required data from the properties.
Any client programmer can use the Component without needing to know anything about how or where the data was obtained. The interface the client programmer needs to know, can be as simple as the properties to set and get, and the one method to call.
Migrating Performable Global Logics
Before transforming existing Performable Global Logics to Callable GLGs, consider whether they are suitable. Global Setup Data items become locally scoped, logic commands that interact with the LINC-cycle are no longer valid and internal transactions become independent (except for the 2200 platform), i.e. if a Callable GLG enters transactions state, it will exit from transactional state before it returns to the calling program.
To migrate a Performable Global Logic you must create a new Callable GLG and transfer the relevant functionality.
Sample
Description
In this example you will create a Global Logic that is accessible from third party applications. Using Developer, you will create a Callable GLG and simulate its behaviour with Developer Test.
For instructions on how to write non-EAE applications that access Callable GLGs, refer to the Enterprise Application Environment Documentation.
Description of Steps
1. Create a Callable Global Logic
- Open the Developer application and load the Sample.mdl.
- To the Activity COMP-ORD add a new Performable Global Logic with the name CUSTDTL. Be sure to check the Callable option before pressing ok.
- Define a Parameter List as follows:
- Write logic to read a customer record using their name
- Modify NINQ to use the new Callable GLG
- Validate all the logics in the Business Segment SAMPLE ready for the next step.
3. Simulating a Callable GLG
- Open the Developer Test and create a database for SAMPLE.
- Open a new session and add a sales rep and several customer records.
- Open the Cust Name Inquiry window (ie NINQ) and press enter.
- All the customers you added should appear.
Specifications are subject to change without notice.
Unisys is a registered trademark of Unisys Corporation.
All other brand names are the exclusive property of their respective owners.
Printed in U S America November 2001