Daniel Becker Bighelini

SPEL API: Overview

Blog Post created by Daniel Becker Bighelini on Jun 13, 2016

Chapter 1

Introduction to BOP

 

Table of Contents

Purpose of this document                                                                   

What is BOP?                                                                                             

High level Architecture                                                                                                                                 

How to learn all of this stuff                                                                                                                         

High level domsrvr design discussion                                           

Business Objects                                                                                                                                           

Factories and Lists                                                                                                                                       

The TOP object                                                                                                                                             

Modifying Dobs                                                                                                                                             

Domsrvr Summary                                                                                                                                       

A high level view of the GUI application layer.                          

Wand files.                                                                                                                                                      

The DISPOB                                                                                                                                                   

.VR files                                                                                                                                                           

Summary                                                                                                                                                        

Command line Interfaces                                                                   

bop_cmd                                                                                                                                                      

bop_msg                                                                                                                                                      

The Web interface                                                                                

Glossary                                                                                                 

 

 

Purpose of this document

 

This document is intended to serve as a starting point / frame of reference for the Bop developers course. It is intended to be read by engineers and field support who need to support and customize existing applications, and to build new applications.  It provides an external or user view of the Bop Application Environment where a user is defined as one who is developing or modifying applications which use this technology.

 

This material assumes you understand the basics of object oriented programming and have at least an acquaintance with the C language.  If you are going to do the exercises you need a UNIX Workstation or NT Workstation upon which you can play that has the latest release of Paradigm installed  

 

Structure of BOP Documents

 

This material is structured into a Programmer's Guide and a Programmer's Reference.  The Programmer's Reference consists of an introductory chapter.  The remaining chapters should be read and the associated exercises performed on Paradigm environment. Each subsequent chapters is designed to ‘peel the onion of functionality’ in the Bop environment. The intent is to expose the pieces in a step by step fashion.  The initial workshops will be based on a employee tracking system.  Later workshops will use the objects already created in the Call manager system.  The items covered are:

 

When provided as part of a BOP class,  please read the inial chapter before first class.

 

  • BOP Overview                
  • Your First Bop Application
  • Adding simple behavior to the Domsrvr
  • More complex Domsrvr behavior
  • Working with Spel and the command line interface
  • Basics of the GUI layer
  • Linking the GUI and the Domsrvr together
  • Using LRELs
  • Events
  • Modifying Call Manager

 
 

What is BOP?

 

Traditional development environments have done a good job of defining a way to store information (Such as SQL databases) and have good tools for defining GUI forms to allow the user to poke at that data.  What is typically missing is the middle layer that glue’s the database to the GUI and defines the application behavior.  The application developer is called on to write code to provide this behavior, typically in some compiled language.  This model begins to break down in Business Process applications (Applications which mimic an existing business process) such as Problem Management.  In these applications the customer wants the application to match their way of doing business.  There is no ‘right’ way to design the application.  To meet these customer needs, we have designed an application framework which can be extensively modified to meet our customers needs.

 

Bop (Business Objects on Paradigm) is an object oriented application environment using distributed objects technology, optimized for fast development of many kinds of business process applications.  It contains facilities to define Business Objects and to bind the attributes of a business object to various underlying data repositories such as an SQL data base.  The behaviors and attributes of these objects are completely late bound and can be customized and extended by the user, integrator, or developer.  The Bop suite of tools includes a GUI tool / viewer which makes building GUI applications quick and relatively painless.  Like object definition, the viewer is completely defined in late-bound configuration and procedure files.  A web interface to BOP is also provided which again provides for easy web application development.

 

What all of that means to you as a developer is that writing code is no longer a major part of developing an application.

 

Let’s define some of the terms we just  introduced.

 

Application Environment:    

Bop is a collection of pieces which fit together to create the business application.  These tools are optimized for development of multi-user, client server, form based business applications.  The bop environment makes the developers job easier and quicker, and provides for great flexibility in the customer product.

 

Distributed Object Technology

We make development easier by utilizing distributed objects.  The objects used in our applications are distributed among various processes and computers around the network with location transparency.  We call methods in these objects by sending messages to them.  In our model processes are peer to peer.  In other words any process can provide objects (be a server) and any process can ask for an object( be a client).  The bop distributed object is similar in concept to a COM object.

 

Business Process Application

We are not optimized for building a spreadsheet,  for word processing, or for building a medical imaging system. We do handle business forms and data quite well.  The original target application was problem and call management. 

 

Business Object

We introduce a different paradigm for software development.  A business object is an object which encapsulates business knowledge and rules.  A collection of business objects can be assembled into applications by some program. A well designed business object will live in many applications at any time.  They lend themselves to re-use.  It makes you ask ‘where does the logic belong’  If it is a business rule, chances are it belongs in the business objet.  If it is application behavior, it belongs in the application logic.  Deciding where behavior belongs, is one of the first intriguing questions you will need to answer in any development.

 

Late Bound Definition,         

The class definitions of our business objects, GUI application, command line tools, and Web Applications can be defined at run time with no lengthy compile-link cycle.  This includes the attributes of our business objects, methods on our business objects and other objects, and behavior.  This late bound definition is what makes it possible for the end user to extensively customize the product for his needs.

 

GUI Viewer

What most end users first think of as the application.  It presents the business objects to the user on a screen, and adds GUI behavior to complete the application. 

 

High level Architecture

The architecture consists of three layers:

  • The Data Repository Layer
  • The Object Repository Layer
  • The Application Layer

 

The Data Repository is where the data portion of objects are backstored. The system currently supports the major Relational Databases as well as a proprietary relational database.  A schema file (*.sch) is part of the Data Repository.  This file provides information to the remainder of the system as to what tables are available, what the columns in the tables are, etc.

 

 
 

The domsrvr (Domain Object Server) is where the Business objects live. It is the Business Object Repository. The objects in the domsrvr are defined and implemented in two types of files.  The majic files (*.maj and *.mod) define the schema of the objects, in other words the class definitions.  The Spel files (*.spl) define the procedural behavior via interpreted C code.

 

Type

Product Files

bopcfg/majic

Customer Files site/mods/majic

Majic

            *.maj

Initial OBJECT specification of product

Initial Customer specifications of local tables

Majic modification            *.mod

product temporary fixes to delivered *.maj files in bopcfg/majic

Customer modifications to either product OBJECT or Customer OBJECT specifications

Spel     *.spl

Either

1) compiled product spel libraries or

2) ptf0***.spl replacements for one or more spell methods in product spel libraries.

Either

1) customer ascii Spel methods

2) optional customer replacements for one or more spell methods in product Spel libraries.

 

 
 

 

The application layer currently consists of three application types. Additional types will probably be defined in the future.  The three types are a command line interface (CLI), a GUI for ‘standard’ application access, and a Web Interface.  Each of the application layer types utilize the same idea of a late bound definition.

 

  • The GUI forms are defined in wand files( *.wnd) which define the display objects that make up the application, and by vr files (*.vr) which define the look and layout of the window.

Type

Product Files

bopcfg/gvr

Customer Files site/mods/wnd

Wand

            *.wnd

Either

1) inital product wand or

2) ptf0***.wnd that replace one or more wand methods in product wnd libraries.

Initial Customer specifications

Visual Resource            *.vr

product temporary fixes to delivered *.vr files in bopcfg/gvr

Customer modifications to either product or Customer specifications

 

  • The CLI interface uses Fragment files (*.frg) which are identical in format to the Spel files.  The Fragment file (IE code fragments) are read by a command line tool and executed.
  • The Web Interface is currently driven by freeaccess.cspl, a Fragment file which defines behavior, and by HTML Template files (*.htmpl) which define the look of the HTML forms.

 

 

 

How to learn all of this stuff

 

The best way to learn a new environment is to work in it.  There are no Wizards or IDE for Bop as yet.  So you will be doing a bit of work in a text editor in order to see results.  We will assume that you are working from an existing Paradigm application.  This makes setting up the environment much easier. In order to reduce the variables in our document we will further assume that you are running the Paradigm Proprietary database.

 

Once you learn how it all fits together, you will be able to make good use of the reference documentation that we supply.

 

The beginning of design for any application is defining what additional objects you need in the domsrvr to support the application.  We can’t begin to talk about this however until we have a better understanding of what a business object is, and how it can be used.

 
 

High level domsrvr design discussion

 

The purpose of the domsrvr is to create and provide useful objects to the application layer in a consistent extensible manner.  In the past, we have had SQL which defines a standard way to store and retrieve data in relational tables on a disk.  Whenever you wrote an application , however, you had to write a fair amount of code to handle the data not stored on the disk, to add behavior to the application, to define ways of retrieving and manipulating lists of data in the application.  The domsrvr provides a standard way of handling this functionality for you so you don’t have to spend time designing and writing that code.  It does this by defining standard Business objects, List objects, as well as Access and Update methods.

Business Objects

Let’s start in the middle and talk about what is a business object without any regard to how you create one or what you can do with it.

 

The internal name for a Business object is a Domain Object (dob) that shouldn’t be confused with the viewer’s Display Object (DOB).  Dobs are what you will be dealing with most often in your applications.  It is the programming object you define which contains the business rules of the organization and which you combine with other dobs to make an application.  A business object has attributes (Sometimes called properties) and methods.  The methods are only accessed by sending a message to the business object asking it to execute the method.  The business object, can be defined to reply by sending a message back to its callers.

 

Each attribute in the dob has a name.  You typically access the attribute by it’s name.  One attribute is always present, the ‘persistent_id’.  This read only string attribute contains an id which will is unique to a single instance of a business object (For example John Smith) and also contains the class name of the object.  For example the object representing John Smith  (A member of the class ct) might have a persistent id of ct:1234.

 

We have several types of attributes in the system.  Creating new attribute types is not supported outside of the domsrvr developers. The attribute types we support are:

Type

Description

Value

A simple concrete value. Current types are String, Integer, Duration, and Date/Time.  An example in our Contact object might be ‘ last_name string’

SREL

A single relation. A reference to another business object.  An example might by ‘my_group SREL org’ where org is another business object which is the department our contact belongs to. Think of SRELS as the unique foreign key of another table.

BREL

A back relation. The ‘other side’ of an SREL. For example, our organization object could have a ‘my_contacts BREL contact my_group’ where my_contacts is a list of all contacts which have this organization as their ‘my_group’ attribute.

Think of BREL as the (non_unique) foreign key of another table.

QREL

A Query relation. A relation which contains a list of objects defined by an SQL type WHERE clause.

LREL

A List relation.  A many to many mapping between two dob’s

 

 

SREL, BREL, and LREL example

 

The data for the attributes are stored in an SQL database.  At this time there is a one to one correspondence to an object class and a database table (This may change in the future .  Part of defining your Business Objects is deciding what columns in the database table you want to bind your attributes to.  We should note however that not all attribute types need to be backstored (BREL and QREL) and that some have a ‘special’ storage not in the ‘main’ database table (LREL).  Additionally you may define Value attributes which are not backstored in the database.  This feature is particularly useful if you need to keep additional scratch state variables or want to define a combo_name(last_name, first_name middle_name) field for Contacts.

 

Dob’s and their attributes will both respond to messages being sent to them (i.e. they have methods).  There are a rich set of methods for access , modification, being notified of changes to the object, etc.  You can define additional methods on the dob if needed.  For example in Call Manager we defined a method of the Call_Request object (cr) to create an activity record which would be properly initialized and which would point to the cr.  This is one major way you have of customizing and enhancing the business object. You can define a method, and provide the procedure to be done when the method is called in interpreted Spel code.

 

The other primary form of modification is in triggers on the attributes and on the Business objects. 

  • Built in trigger points are available to allow you to define default rules for attribute values.
  • You can use both pre-validate and post-validate triggers on an attribute changing that can test for valid input, or have other side effects.  For example, I could define a pre_validate trigger on the last_name attribute in the contact object to make sure the first letter is Capitalized (or I could coerce it to be Capitalized) and when it is changed, I could re-build the combo_name attribute.
  • On the Business Object you define triggers to be called when the object is created, instanced from the backstore, validate prior to being saved, post_validate prior to being saved, and after being saved.  These triggers can further be filtered to only fire based on specific values of specific attributes in the business object.  For example I could set up a trigger to fire whenever the status of a Call Request is being changed to Closed when the object is being saved.

 

Remember that when you get a reference for a dob (say a contact for Sam Smith), that all you have is a reference.  The actual object for Sam Smith is ‘really’ in the Domsrvr.  You present requests to manipulate that object, and the domsrvr will honor those requests as best it can.  Also remember that what you really have is a public interface to the Sam Smith object.  Multiple users may be requesting the Sam Smith object.  and could be making changes to it. You are protected from those other accesses until they save their work however.

 

The most interesting question now is how to get a dob from the domsrvr.

 

Factories and Lists

 

How do you get the business objects to display and manipulate.  The answer is from a Factory object or a Domset object ( The Domset is the List object)

 

A Factory is the object that will provide you with a dob if you give it the persistent_id.  It will make a new dob for you if you ask it to.  You can define methods on the factory as you can in the Business Object.  For example, for the knowledge manager we defined a method in the Solution factory to take a Description field and return the keywords that are contained in the description field.

 

A Factory will also create for you the List object (Called a Domset ). A Domset is designed to hold a set of business objects that match selection criteria.  A Domset can be defined to sort the dob’s based on the attribute values.  In this way you can set up a Call Request list to sort by Assignee, or Status, etc. Domsets have some unique features that should be mentioned.

 

  • Domsets can be static or dynamic.  A dynamic Domset will be notified whenever a dob is changed and it matches the selection criteria.  For example, if you have a dynamic list to show all call requests assigned to you, and you re-assign one of your call requests to someone else and save the change, the dynamic list would remove the call request that you changed.
  • For efficiency, lists can be shared by users.  You can define global lists to (for example) keep track of the number of priority-1 Call Requests.

 

A factory has a set of standard lists.  These are lists that you know will always be there.  You can define many options about the standard lists. We will discuss these later.

 

Factories (like dobs) have attributes.  In this case the attribute is a Producer.  We will not talk about producers too much.  For the most part they are an implementation detail in the Domsrvr itself.

 

We get Domsets from Factories by sending a message to the factory requesting a Domset.  Where do we get Factories from.?

 

The TOP object

 

Factories are attributes of the TOP object.  The TOP object is the well known interface into the Domsrvr.  It is where you always start.  It is always possible to send a message to TOP because you know it’s name.  You can always get a Factory object by asking TOP.

 

For example, if you want to get the first call request that matches some selection criteria, you could send a message to the TOP object to be dispatched to the cr factory to get a Domset object.  Send a fetch command to the Domset, wait for the Domset to get in some items.  Get the first one.

 

The top object also provides the user with instances of the Group Leader object. This object is used in concurrency control.  The TOP object is also where additional security will be implemented.

 

Modifying Dobs

 

Instead of a more common read/write lock approach, the BOP environment utilizes a check-in / check-out metaphor with notification of changes as it’s way of handling revisions and update conflict.  The user requests a special object from the TOP object named the Group Leader.  When the user wants to modify the attributes of a dob, he sends a ‘checkout’ message to the group leader.  If the group leader can check out the object he does so and tells the user that the checkout succeeded.  If some other group leader has the object checked out the checkout fails and the user is notified of this.  Once the object is checked out, the user can make changes.  The user can checkout additional objects on the group leader. When the user has completed his changes, he checks in the group leader which commits all of the changes.  Any other consumers of the Bop(s) which are changed can register for changes in the attributes of the Bop.  They would be notified of the change in attribute value after the chicken is complete.

 

Domsrvr Summary

 

  • Distributed Business Object Server
  • Single derivation available in all objects
  • Consistent Interface to all objects
  • Relations between objects are attributes
  • Late Bound
  • Behavior via added methods and triggers on object or attribute
  • Access via Messaging
  • Interpretive language to define procedural behavior

 
 

A high level view of the GUI application layer.

 

The best way to think of this layer is as an application that reads .wnd (Wand) files, and .vr (Visual Resource or Form) files and creates the application the end user manipulates.  The two keys to understanding the vbop layer are the Wand files, and the VR files.

 

Wand files.

 

Consider designing a new GUI application.  You have split the application into major subsections, and have divided the subsections into individual forms.  You want to be able to invoke the various subsections and forms you have defined from various locations from within the application. For example if your application is trouble ticketing, the trouble ticket detail form should be able to display and manage failed resources, action lists, and details of actions.  You might wish to invoke the trouble ticket detail form from a list of open tickets, or from a list of work assigned to ‘Fred Smith’.  This is the part of the application process that WAND is designed to address. 

 

In WAND you define sections of the application which may consist of multiple forms, and the relationship between those forms.  WAND also allows you to define the context information required to invoke a form or subsection.  This allows you to hook up the form in any part of the application that has the needed context.

 

For example, a ticket detail form which has sub displays, (Actions, failed resources, etc.) associated with it could be defined to need as it’s only context the persistent id of the trouble ticket to display.  You could then ‘hook up’ the ticket detail anywhere the id is available.  From a list query screen, from a list of tickets assigned to Fred, or from a Call Manager screen that has an associated ticket. 

 

Unlike pure visual programming environments, where behavior is tightly bound to a particular form screen, the wand approach allows you to define behavior and relationships in one location, and associate one or more forms with them. This means that in our Ticket Detail example above, I could have a different form which is targeted towards different users, or which varies based on the place I invoked the Trouble Ticket detail.  I don’t have to re-create the application functionality with each form the user sees.

 

The DISPOB

 

The major unit of WAND configuration is the Display Object (DISPOB). The DISPOB encapsulates a related group of information which can be displayed on some form.  In early learning states, it is useful to think of a DISPOB as the ‘code’ that drives a ‘form’ although later you will see that this is not strictly true.  A DISPOB can also be a row in a grid, or a special section of a form.

 

As you will see in our early tutorials, the vbop application queries the domsrvr for object schema information and creates a DISPOB with default attributes for the objects in the domsrvr.  This makes writing code easier (less to do) but makes understanding it a bit harder (it’s hidden from you).  It is therefore useful to briefly define the major parts of a DISPOB.

 

The easiest way to think of the default  DISPOB’s that are automatically created for you are is as one of two types. A detail DISPOB whose function in life is to display a single dob from the domsrvr.  A list DISPOB whose job is to display some Domset from the domsrvr. A detail DISPOB can of course display lists associated with the object (such as a list of call activities associated with a call, or a list of call requests associated with a customer). 

 

Additionally we have two flavors of each kind of DISPOB - managed and not managed.  A managed DISPOB means that the viewer will only have one instance of the DISPOB at any time.  For example, if I decide that my application will have a single list maintenance for Location, and when the user selects Location from the menu while the Location is already up, we will raise the Location form to the top instead of creating another form.

 

With our default DISPOB’s we have a rich set of built in behavior.  From our list we can create new objects, search for specific objects, save changes, etc.  We even create default selector helpers for our objects.  What the form looks like is under the control of  the .vr file associated with the screen we are putting up.

 

.VR files

 

.vr files are created by a GUI form editor.  This editor allows you to lay out your dialogs , to give the dialog a name, and to associate tags with the objects you put on the form.  When the DISPOB is created, it looks for the named form and puts it on the screen.  It then gets the tag names from the form for each widget that is in the form, and puts the data from the domsrvr (via the DISPOB) onto the screen. For example, if your DISPOB was a loc_detail (Location Detail) and you wanted to display the location’s description attribute on the form, you would put a text edit widget on the form and set the tag to ‘loc.description’. 

 

BOP also support the idea of form groups (same functionality but with a different implementation from Problem Management).  A user can have a different form from other users either based on who the user is or what group they belong to.  This gives flexibility in controlling access and layout to different users.  Like the WAND language, the forms are completely late bound. No re-compilation is required to display a new form.  The form group feature allows you to easily set up different looking and functioning screens.  For example, you could use the standard call manager screens for you help desk analysts, but set up a simpler screen for a dispatcher who gets calls when the help desk is swamped..

 

Summary

 

  • DISPOB as Logical form.  Defines behavior
  • DISPOB defined in Wand files
  • .vr file to define look of form
  • Tags in .vr files to tie form to DISPOB

 
 

Command line Interfaces

 

The behavior of BOP is defined in large part via interpretive code.   BOP has two types of command line interfaces.

bop_cmd

BOP has a command line utility which can be invoked with a file name (containing code to be interpreted) and a function within that code to execute.  If you are defining a command line interface, you will be sending messages to the domsrvr, executing code you write etc.  This Spel code runs within bop_cmd???

bop_msg

BOP has a command line utility which can be invoked with a function within the domsrvr to execute. This code runs within the domsrvr.  If the function were to run for a long period of time ( example crarcpurge ) and the bop_msg were killed, the function would continue to run.

 

 
 

The Web interface

 

The web interface is managed via a separate web server daemon.  It communicates to the domsrvr using the standard BOP messaging.  The current webengine was not documented for customer modification. (product packaging, not a technical decision).  What you can customize is the template files which define the forms.  This is similar to defining vr files in the GUI application.

 
 

Glossary

.maj files: 

.sch files

.spl files

.vr files

.wnd files

Environment variables
NX_BPTIMEOUT
NX_DSSORT  BINARY EN INTL INTL_NOCASE NOCASE EN_NOCASE
NX_DSCONFIG
NX_MODS

Application:
An executable which provides useful work for the user.

Attribute: 
Part of domsrvr object.  Sometimes called Propertys.  Attributes have names  by which they can be accessed.  They represent other objects, concrete data types, Single relations to another object, Query or Back relations to another object class, or List relations.

BOP:
Business Object  Paradigm.  An application development and runtime environment which is used to define applications.

bop_logging:
An executable which will print messages to a file.  A very useful debugging routine.

bop_sinfo
An executable which will print various details about the domsrvr schema

bop_tps
A  ‘thread ps’ utility.  This tells you where any active threads in your interprative code may be.

Brel Attribute
An attribute on a dob.  This is the ‘Back’ relation.  It can best be thought of as a list of objects where the definition of what is in the list is based primarily on some other Srel attribute

Business Object
An object which encapsulates a business funciton.  We build applications from business objects.  In the domsrvr the business object is called a domain object or more commonly a Dob.

Business Process Application
An user application of the type that lends itself to a Busines Object approach.  Business Process Applications are designed to track events, replace paperwork, automate workflow, etc.

Business Rules
The rules of a Business Object.

Call Manager
An application in the Paradigm suite of products.  Call Manager is based on the BOP technology.

catcher method
Some calls you make to the domsrvr will cause multiple messages to be sent to you at later time.  You need to provide a catcher object and a catcher method to ‘catch’ these later asynchronous objects.

catcher object
Some calls you make to the domsrvr will cause multiple messages to be sent to you at later time.  You need to provide a catcher object and a catcher method to ‘catch’ these later asynchronous objects.

Checkout/Checkin
The metaphor for revision control in the BOP world.  You get an object and, if you want to make a change, you attempt to checkout the object. Later you check it back in when your changes are complete. 

combo_name field
A field in the call manager contact object which combines the first, last, and middle names.

cursed row
In the GUI application.  When you are viewing a grid on the screen and your cursor is located on some row, that is the cursed row.

dbspy
An executable which examines the low level slump calls to the database daemons

dialog
A screen construct you can define for the user. Sometimes called a window.

DISPOB
A Display object in the Bop Viewer.  A Dispob encapsulates application behavior separate from the dialog which is used to present it to the end user.

distributed objects
A style of object oriented programming where the objects you are manipulating may be in any process space.

Dob (Domsrvr)
A Business Object.

DOB (vbop)
The object which wraps a Dob (Domsrvr) for you and manages the display.

Domain Object
Another word for Business Object.

Domset
The list construct in BOP.  A domset is a list of dobs that match some selection criteria.  They are typically sorted by multiple keys.

domsrvr
The executable which serves domain objects (dobs or business objects).  This is the primary server in the Bop world.

editwin
The executable which provides a drag and drop GUI to create and modify the Dialogs that are part of the GUI application.

Ensemble
A collection of objects in the domsrvr that co-ordinate to handle some class of business object.  Typically is is the Factory, Producer, and Dob itself.

Event Trigger
A way to have an object be activated at some time in the future to do some work.  With no human intervention.

factory
The object which provides Dobs and Domsets to the user

Fast Channel
A way that two processes can set up a ‘faster’ communication channel under Slump.  The two processes in fact set up a provate semaphore to communicate over.

Form Groups
A way to provide different looks and functionality to different users.  A form group can be defined for some functional group or hardware configuration (like VGA).  The user will use the forms in the form group instead of the default forms.

Group Leader
Used in revision control.  The group leader is a construct that actually manages doing the triggers and checkin logic.

GUI Viewer
The application that manages the GUI for the end_user applciation (vbop)

Late Bound Definition
A feature of bop.  The atrtributes and behavior of the objects and the application can be defined and re-defined at the customer.

LIST
A vbop construct which is a list of dobs.

Lrel Attribute
The list relation attribute.  An Lrel attribute maintains a many to many mapping between objects.

Majic files
The files that define the object schema. The file extensions are .maj or .mod.

Managed Dispob
A dispob that is managed.

Managed
A vbop concept,  If there is a managed display object, there will be only one instance of it allowed at any time.  For example, if Contact  detail were managed, and the user attempts to bring one up while there is another active, the existing instance will be raised to the top, and the data in it will be set to the new context.

Message
The way we communicate between bop applications.  The messages we use are asyncronous and provide for reply mechanisms.

Method
A receptacle for a particular message. Similar in concept to a function on the distributed object.

METHOD
In vbop - some wand code which can be associated with a button.

NX_ROOT
The root to the Paradigm applications. An environment variable you need to set before developeing applicaitons

pdm_editwin
The script to start up the editwin application.

pdm_init
The script that starts the Paradigm daemons

persistent_id
Each dob has a persistant id.  The persistent id is a string which combines class information with instance information.

Problem Manager
One component of the Paradigm system. Problem manager is based on older less flexible technology.

Producer
The object which instances dobs from the backstore.

Public/Private metaphor
The idea of a ‘private’ object that actually contains the data and methods, and an access object which we make for each user which gives seamless access to the private object.

Qrel Attribute
An attribute of a Dob which is a list of other objects.  The list is defined by some where clause (hence the Query)

Reference Count
Distributed objects have a built in reference count so the application will know when the object may be deleted.

reply method
When you send a message to some object, you usually want the object  to reply. To do this you define in the message that is sent to the object a catcher object, and a catcher method.

reply object
When you send a message to some object, you usually want the object  to reply. To do this you define in the message that is sent to the object a catcher object, and a catcher method.

Schema files
The files that define the database schema for the environment.

slspy
A utility that looks at the raw low_level messages in the BOP environment.

slstat
An executable which provides slump status information.

Slump
The core messaging facility used in BOP.

Spel files
The files that contain the Interpreted C behavior need by the domsrvr.  They have an extension of .spl

Srel Attribute
An attribute which represents a single relation.  Such as employee type, or assignee of a Trouble Ticket.

Standard Lists
Each factory defines some standard domsets it supports.  We refer to these as the Standard Lists.

TOP
The object at the ‘top’ of the object instnace hierarchy in the domsrvr.  This object always has the same name so you can always send messages to it.  This is the entry point into the domsrvr.

Trigger
A function that has been defined to be called at some point in the business processing .  Triggers may be conditional of various attribute values.  They may be applied to Attributes, or Dob.

Value Attribute
An attribute which is a simple concrete type such as string or integer

vbop
The executable which controls the GUI applicaiton.

Vre files
The Visual Resource files that define the dialogs for the application.  These are created and edited by the editwin application.

Wand files
The files that define GUI applicaiton behavior.

Widget tag
The string that the vbop application uses to decide where to hook up the widget to the data structures in the Dispob.

Widget
Some item you place on the Dialog to place a label, add a text field, line,  button, grid, etc

Window
Another name for a Dialog

Outcomes