Download Xellerate 5.0 Developer`s Guide

Applications Anytime Anywhere
Xellerate 5.0
Developer’s Quick-Start Guide
FOR INTERNAL USE ONLY
Document version 1.0
Proprietary and Confidential
Copyright © 2000, Thor Technologies, Inc. All Rights Reserved
Table of Contents
1.0. INTRODUCTION.................................................................................................................. 1
1.1. PRODUCT OVERVIEW ......................................................................................................................... 1
1.2. CLIENT APPLICATION ........................................................................................................................ 2
1.3. MIDDLEWARE SERVER ...................................................................................................................... 3
1.4. DATABASE SERVER ........................................................................................................................... 3
2.0. RUNNING XELLERATE..................................................................................................... 4
3.0. DEVELOPMENT ENVIRONMENT SETUP .................................................................... 7
3.1. OVERVIEW ......................................................................................................................................... 7
3.2. INSTALLING JAVA SDK ..................................................................................................................... 7
3.3. INSTALLING CS-RCS CLIENT ............................................................................................................ 8
4.0. SOURCE CODE OVERVIEW............................................................................................. 9
5.0. BUILDING XELLERATE.................................................................................................. 10
5.1. COMPILATION .................................................................................................................................. 10
5.2. EXECUTION ...................................................................................................................................... 10
6.0. PRODUCTION TEST ENVIRONMENT ......................................................................... 11
7.0. DATABASES AND DATA MODEL ................................................................................. 13
8.0. ORDER DATABASE STRUCTURE AND LOGIC......................................................... 17
8.1. ACCOUNT INFORMATION ................................................................................................................. 17
8.2. ORDER INFORMATION ...................................................................................................................... 18
8.3. ORDER APPLICATION DATA ............................................................................................................ 21
9.0. MIDDLEWARE ARCHITECTURE ................................................................................. 22
9.1. OBJECT MANAGER ........................................................................................................................... 22
9.2. SESSION MANAGER.......................................................................................................................... 22
9.3. DATABASES ..................................................................................................................................... 22
9.4. QUERYING........................................................................................................................................ 22
9.5. SAVING ............................................................................................................................................ 23
9.6. CLIENT SIDE OPERATIONS ............................................................................................................... 23
Xellerate 5.0 Developer’s Quick-Start Guide
1.0. Introduction
The Developer’s Quick-Start Guide provides an introduction to the Xellerate architecture
and will enable you to set up your development environment for Xellerate 5.0. This
document provides an overview of the following topics:
• Development environment setup
• Source code overview
• Building Xellerate
• Databases and data model
1.1. Product Overview
Xellerate 5.0 evolved from CarrierBase 4.0, which is commonly categorized as an order
provisioning software. The goal of the product is to minimize the time between order
acceptance and delivery. It provides a powerful yet simple way of defining, tracking,
forecasting and analyzing business processes. Initially the target market for the product
was the Telecommunications Service Providers. Winstar Wireless, for example, used
CarrierBase and reduced its delivery cycle by 94%, from 39 days to 3 days.
Xellerate 5.0 is a major rewrite of CarrierBase 4.0 to reposition the product for use in the
emerging Application Service Providers (ASPs) market. Various components of the
product are illustrated in the following figure.
Xellerate Core Management Engine
Process/Event Engine
Customer Mgt.
+
Thor Technologies, Inc.
Export/Import Mgr.
+
Automation Mgr.
+
Page 1
Xellerate 5.0 Developer’s Quick-Start Guide
The Xellerate 5.0 Core Management Engine consists of the following
components:
•
•
•
•
Process/Event Engine - allows the administrator to easily set-up and configure
processes on the fly; provides the capability to automate exception handling and
process evaluation; and facilitates the assignment and management of tasks to the
various involved players.
Customer Management - provides a comprehensive representation of all
customer information together with their contacts, order history and outstanding
issues; ties directly into the Process/Event Engine and provides therefore a realtime view of all customer related issues.
Export/Import Manager - allows the administrator to set up complex export and
import processes; is tightly integrated into the Process/Event Engine and provides
therefore a powerful tool for the management of interfaces to other systems.
Automation Manager - allows the administrator to define the automation of any
desired process and also provides the capability to automate export/import
processes.
Development of Xellerate 5.0 included migration of CarrierBase 4.0 from a two-tier
client-server architecture to a three-tier architecture, and rewriting the entire source code
base in Java. Xellerate’s three-tier architecture consists of the client application, the
middleware server and the database server, as illustrated below:
JDBC
Corba
Client
App
Middleware
Server
Database
Server
The middle-tier in this new architecture can be viewed as a combination of some of the
functionality of CarrierBase 4.0 client and the functionality contained in triggers and
stored procedures contained in the CarrierBase 4.0 database
1.2. Client Application
The first tier, client application, corresponds to the Xellerate application, which includes
the GUI component. Xellerate 5.0 client applications never interact directly with the
database. The login process consists of contacting a middleware server, providing the
login credentials, and then letting the middleware server validate them. Queries are
executed and dispatched to the middleware server that retrieves the result set as a return
value. The middleware server saves and deletes at the client's request. The client has no
knowledge of the actual operation being performed.
There are also a few lower-level architectural differences between Xellerate 5.0 and
CarrierBase 4.0. One of the most apparent is that Xellerate forms cannot generate SQL
queries dynamically. Instead, the base query is specified for the form and each field on it
is assigned a column relative to a result set column. In addition, database writes are not
done by the client but dispatched from the client to objects in the middleware that are
designed to accomplish that purpose.
Thor Technologies, Inc.
Page 2
Xellerate 5.0 Developer’s Quick-Start Guide
1.3. Middleware Server
The second tier, middleware server, implements all the business logic. It acts as a bridge
between the client application and the database. This is the only component that has
direct access to the database itself. Upon startup, the server basically consists of a sole
CORBA object that responds to client requests such as logins, queries, saves and deletes.
The server establishes a database connection for every client login and uses it to process
client queries.
For every save or delete made by the client, the middleware creates an object to serve that
request, registers the object with the ORB, and notifies the client that the object is ready
to serve the client's request. The client specifies which record it wishes to operate upon
and then sends all the relevant data to the server for processing. The object created by the
server runs all business rules on the data and then generates and executes the necessary
SQL statements to complete the client's request.
1.4. Database Server
The third tier, database server, implements the Xellerate data model. Xellerate 5.0
database maintains the same data structure used in CarrierBase 4.0 without any triggers,
stored procedures, and views because all of the business logic is implemented in the
middleware. Also, removing the processing load from the database server makes the
application independent from the database implementation and the vendor. Therefore,
application in theory should be able to run on any ANSI SQL compliant database.
Thor Technologies, Inc.
Page 3
Xellerate 5.0 Developer’s Quick-Start Guide
2.0. Running Xellerate
To run the Xellerate 5.0 client from the command line, you need to execute the
following:
Thor.CarrierBase.GUI.tcAppWindow class
Java Thor.CarrierBase.GUIBase.tcAppWindow
This can also take several parameters: -nostartup Xellerate 5.0 allows you to set a startup
window or windows, which are loaded whenever you start the client. This option will
turn those windows off.
-server database name
= Name of the database to be used.
-user login name
= The login name.
-password password
= The login password.
Databases currently in use:
• Thor
• Java
• WinstarTest
• JavaRegressionTest
• WinstarFull
For example:
java Thor.CarrierBase.GUIBase.tcAppWindow –nostartup –server java
–user sa –password sa
An example batch file to run the client is located at:
\\lolita\e$\devel\java\carrierclient.cmd
To be able to run Xellerate using this batch file, first, the developer should map the
network drive (T:\) to the E:\ drive on Lolita as follows:
1. Launch your Windows Explorer.
2. From the Tools menu, select Map Network Drive.
3. From the Drive: drop-down, select T:\.
4. From the Folders drop-down, select \\Lolita\e$
Then the developer must create a shortcut to the Xellerate application as follows:
1. Right-click anywhere on the surface of your desktop.
2. In the context menu that appears, move the mouse pointer over “New” and
select “Shortcut” in the sub-menu. This will bring you to the Create Shortcut
wizard.
3. Type, “T:\Devel\Java\CarrierClient.cmd” into the text box (this
assumes you mapped Lolita to your computer as described above) and click
the Next button.
4. On the next screen, type “Local CarrierBase” into the text box and click the
Finish button.
Before running the Xellerate application, check with your system administrator about
your login information (database name, user id, password). Typically, we use the “Java”
database for testing purposes.
Thor Technologies, Inc.
Page 4
Xellerate 5.0 Developer’s Quick-Start Guide
Finally, double-click on the desktop shortcut labeled, “Xellerate” to run the client. This
will display the following login screen:
Running the client assumes that you are connecting to an already running
Server/Object/Manager. To run it locally, you must execute both the
Thor.ServerManager class and Thor.ObjectManager class. You should
always specify a separate naming context for your server so that it does not interfere with
everyone else. You will need to pass the property CBASE.ContextName with a unique
name (your hostname) to the JVM for both the client and the server by using –D flag
java –DCBASE.ContextName=CRASH Thor.ServerManager
java –DCBASE.ContextName=CRASH Thor.ObjectManager
java –DCBASE.ContextName=CRASH Thor.CarrierBase.GUIBase.tcAppWindow
Thor Technologies, Inc.
Page 5
Xellerate 5.0 Developer’s Quick-Start Guide
After you successfully login to Xellerate, the following explorer screen appears:
For additional information, the complete Thor documentation page is located at:
http://bob/documentation/Java/revisedlibrary/index.html.
This page includes links to the tutorial series and the full API documentation.
Thor Technologies, Inc.
Page 6
Xellerate 5.0 Developer’s Quick-Start Guide
3.0. Development Environment Setup
3.1. Overview
CS-RCS is the current version control system at Thor. This section outlines how the
developers should setup their development environment using CS-RCS. Before installing
the development software check your drive mappings to make sure that the network drive
(T:\) is mapped to the E:\ drive on Lolita.
Before you start development in the Xellerate environment you will need to install the
following software:
• Java 2 SDK ver. 1.2.2_006 – Java Software Development Kit
• RCS ver 2.5 (CS-RCS) – Version Control System
The installation software will require administrative privileges. Please check with your
system administrator about this.
3.2. Installing Java SDK
The Xellerate application currently operates on the JDK 1.2.2 runtime environment. To
install the Java Software Development Kit, run the following executable file located at:
\\lolita\e\Software_Installs\Java\JDK1.2\jdk-1_2_2_006-win.exe.
After the installation, verify that the JDK runtime directory <install_dir>\bin
is in your system’s PATH variable by typing, “echo %path%” at the DOS command
shell. If the \bin subdirectory is not there, then you should add it to your PATH using the
System Properties dialog box from the Windows Control Panel.
Thor Technologies, Inc.
Page 7
Xellerate 5.0 Developer’s Quick-Start Guide
3.3. Installing CS-RCS Client
The CS-RCS version control system enables you to check in/out your Java source code
files. We currently have five projects that are actively being used:
• DataAccess – Lower-level data access components
• Server – The middleware server
• DataObjects – Data objects and translation support
• GUIBase – Core components of the client
• Xellerate – Everything else.
Although work is freely developed in the Xellerate environment, (anyone can work on
anything) several components have been assigned to specific individuals including
DataAccess, Server, DataObjects, and GUIBase. These components are strictly Off Limits
and should not be modified, added, or deleted unless explicitly instructed to do so. Please
see your system administrator if you have any questions.
To install CS-RCS version control software, run the following executable file, located at:
\\lolita\e\Software_Installs\cs-rcs\SETUP.EXE.
At the Component Software RCS Version 2.5.040 Setup dialog box:
1. Select, Workstation Setup to install CS-RCS on an additional workstation in a
networked workgroup environment. The License Agreement window appears.
2. Click the Next button and the User Name dialog box appears.
3. Type your assigned current user name in the appropriate field (or ask your
system administrator if you don’t have one). The Workstation Set up dialog box
appears.
4. At the Common Repository Tree Root field, type \\lolita\e\DEVEL\RCS in
the appropriate field and click the Next button. The Program Location dialog box
appears.
5. Accept the default Destination Folder, c:\program
files\componentsoftware\cs-rcs and then click the Next button. The
system starts copying the appropriate files.
6. Click the Finish button to complete the CS-RCS installation.
7. Click the Yes button to reboot your computer and enable the new settings. The
CS-RCS online help file appears the next time you reboot. You can navigate
through the help topics for additional information or click the Cancel button to
close it.
For more information regarding CS-RCS, refer to the following user documentation
located at: \\lolita\e$\Software Installs\cs-rcs\CS-RCS.DOC
Thor Technologies, Inc.
Page 8
Xellerate 5.0 Developer’s Quick-Start Guide
4.0. Source Code Overview
The complete Xellerate 5.0 source code consists of several JAR files. The source is
divided among the following five CS-RSC projects:
• DataAccess – Low-level data access components
• Server – Middleware server (server .jar)
• DataObjects – Data objects and translation support
• GUIBase – Base classes for the client
• Xellerate5.0a1 – Client code
The projects are setup as a hierarchy, such that DataAccess is independent of other jars.
Server is dependent only on DataAccess. DataObjects requires Server and DataAccess.
GUIBase requires DataObjects, Server and DataAccess. Lastly CarrierBase jar depends
on all other jars.
Development normally takes place within the Xellerate5.0a1 project. Each project is
represented by a Java archive (Jar) file, which collectively forms the following package
hierarchy.
Directory
Xellerate/
Dialogs/
Editors/
Events/
OrderContentItemEvents/
ScheduleItemEvents
Extm/
Forms/
GUIBase/
text/
GUICore/
Images/
DataAcess/
Server/
Util/
Java Package Name
Thor.Xellerate
Thor.Xellerate.Dialogs
Thor.Xellerate.Editors
Thor.Xellerate.Events
Thor.Xellerate.Events.OrderContentItemEvents
Thor.Xellerate.ScheduleItemEvents
Thor.Xellerate.Exlm
Thor.Xellerate.Forms
Thor.Xellerate.GUIBase
Thor.Xellerate.GUIBase.text
Thor.Xellerate.GUICore
Thor.Xellerate.Images
Thor.DataAccess
Thor.Server
Thor.Util
It is easier to use local copies of files that you are actively working on and also with the
class library, located on Lolita e$, for the rest of the classes.
For more information regarding the Xellerate framework (development, Java classes,
components, etc.) please refer to the following tutorial series located at:
http://bob/documentation/Java/revisedlibrary/index.html
Thor Technologies, Inc.
Page 9
Xellerate 5.0 Developer’s Quick-Start Guide
5.0. Building Xellerate
Before compiling any source code files (.java), developers should confirm if their T:
drive is mapped correctly to Lolita e$: and that the following command file is executed at
the command line:
\\lolita\e\DEVEL\Java\classpath.cmd
This will set the classpath variable to point to the appropriate jar files and directories as
required by the application.
If your T: drive is not mapped to Lolita, then copy the classpath.cmd file to your local
drive and modify the first line of the file to reflect your drive mappings. Whereas ‘.’ is
the first entry in the classpath variable and indicates you must compile and execute your
code from the root directory of your Xellerate project. This can be modified to point to
your development directory so that Xellerate can be compiled and executed from
anywhere.
5.1. Compilation
Specify the location of your changes by inserting the working directory in front of the
classpath variable when invoking the Java compiler.
For example,
javac –classpath <local_classpath>;%classpath% *.java
5.2. Execution
Start the Xellerate application by invoking the Java Virtual Machine with the following
command arguments
-DCBASE.ContextName=lolita
The following argument is the entry point to the Xellerate application:
Thor.Xellerate.GUIBase.tcAppWindow
Thor Technologies, Inc.
Page 10
Xellerate 5.0 Developer’s Quick-Start Guide
6.0. Production Test Environment
The following diagram shows how the system architecture is implemented for the
production environment.
Thor Technologies, Inc.
Page 11
Xellerate 5.0 Developer’s Quick-Start Guide
The following diagram shows how the network architecture is implemented.
Thor Technologies, Inc.
Page 12
Xellerate 5.0 Developer’s Quick-Start Guide
7.0. Databases and Data Model
The following diagram shows how the three relationship types are used and how their
cardinality is specified below the connection.
On the following two pages, Diagrams A and B show the database relationship model for
the most important tables. The black boxes indicate the major tables while the white
boxes indicate how the tables are joined between them to show how many-to-many
relationships are implemented.
Diagram A displays the descriptive names of the databases used within the boxes while
Diagram B displays the actual database table names within the boxes.
Thor Technologies, Inc.
Page 13
Xellerate 5.0 Developer’s Quick-Start Guide
Diagram A – Descriptive Names
Thor Technologies, Inc.
Page 14
Xellerate 5.0 Developer’s Quick-Start Guide
Diagram B – Actual Database Table Names
Thor Technologies, Inc.
Page 15
Xellerate 5.0 Developer’s Quick-Start Guide
The following table is a list of database tables used frequently by Xellerate:
(P)rimary
(S)tatic
Table
(J)oin
(D)ynamic
Description
ABT
P
D
Holds all BTNs (Billing Telephone Number) for a given account.
ACN
J
D
Links account and contacts.
ACT
P
D
Account table holds information on entities that order services.
ALN
J
D
Joins ACT (account) and SIT (Site) tables.
ATS
P
D
Stores services or can be ordered by accounts and rates apply.
CLN
J
D
Joins contact (CON) and location (SIT) tables.
CON
P
D
Stores all contacts for the system. Contacts can be related to different entities.
GSC
J
D
Join table between SCH (scheduled items) and CON (contact information).
GSI
P
D
Schedule item assigned to user group.
LOC
P
D
The LOCATION table contains information about client locations.
MIL
P
S
Milestone tables. Milestone keys and names.
MSA
J
S
This table holds the association between milestones and a group of users.
MSG
J
S
Joins MilestoneStatus (MST), status (STA), and user group (USG) tables.
MST
J
S
Joins milestone and status tables.
O2C
J
D
Joins ORC and CON (Contact) tables.
ORC
P
D
ORD
P
D
This entity holds the detail on each order. This could be considered the items section of an invoice.
ORDER contains all information that is necessary to complete an order regardless of the type of service
being ordered.
OSI
J
D
PHO
P
D
PKC
J
S
PKG
P
S
This table keeps track of which types of service go with which package
Consists of names and system keys of service packages, which consist of a group of services from the TOS
table.
This is a universal scheduling table that holds all milestones for all activity in the system. When a service is
ordered, all its corresponding milestones and scheduled dates are inserted in this table. This table supports
group and individual 'To Do' Lists.
This table relates specific orders to milestones
Holds all communication addresses for this contact -- e.g., contact telephone numbers, fax numbers, e-mail,
etc.
SCH
P
D
SIT
P
D
The SIT table contains information about sites. Sites are subsets of locations.
STA
P
S
Status Codes
TOS
P
D
Holds all services and their individual features or properities
UGP
P
S
Defines a group of users
USC
J
D
Joins SCH (schedule item) and CON (contact) tables.
USG
P
S
Join table between users and groups
USI
P
D
Store all user-defined milestones. A user can create and store their reminders and action items.
USR
P
D
Stores all information regarding a user.
Thor Technologies, Inc.
Page 16
Xellerate 5.0 Developer’s Quick-Start Guide
8.0. Order Database Structure and Logic
The following describes the primary tables used in Xellerate:
8.1. Account Information
The account information structure is used for storing information specific to the customer
account. In order for a customer to order any service, the customer’s account information
must be present in the database.
Accounts Table (sysadm.act)
The account table is the top-level table in the Xellerate order hierarchy. The account table
contains information specific an account itself, such as the account name and primary
billing telephone number.
Major fields
Account Key
act_key
Account Billing
Telephone Number
Account Name
act_btn
Agent ID
act_agent_id
act_name
The system-generated (primary) key identifying the
account record.
The account’s primary billing telephone number
The name of the account. This is usually just the
customer’s name.
The name of the account’s agent. If the customer was
brought in by a specific agent, that agent’s name will
be used; if the account was entered directly into
Xellerate without an agent, the System Agent is used
as the agent.
Billing Telephone Number Table (sysadm.abt)
The billing telephone number is used to identify the billing telephone numbers for a
specific account. For most residential accounts, this is the customer’s phone number.
However, many businesses will use multiple billing telephone numbers. Each branch or
division of the business is assigned its’ own billing telephone number, and all of the
services used by that particular unit of the business are billed under that number. Each
account will have at least one billing telephone number entry.
Major fields
Account Key
Billing Telephone
Number Key
Billing Telephone
Number
Thor Technologies, Inc.
act_key
abt_key
abt_btn
The key identifying the account that the billing
telephone number is associated with. This is a foreign
key reference to the act_key in the account table.
The system-generated (primary) key identifies the
Billing telephone number record.
The billing telephone number.
Page 17
Xellerate 5.0 Developer’s Quick-Start Guide
8.2. Order Information
The order-level structure is the next part in an order for a particular service. This
component will contain information about the services the customer has ordered and the
progress of their order.
Order Table (sysadm.ord)
The order table is used to map orders for specific services back to the customer’s account
information, as well as storing customer-provided information about the order. Many
larger business customers use their own internal tracking system for orders, such as
internal order numbers and project numbers stored in the order table. Since orders are not
always placed under the account’s primary agent and billing telephone number, the order
table can be used to assign a different agent and billing telephone number to each order.
However, an order does not necessarily identify an order for a single service; many
requests for several types of services can be included as part of one order.
Major Fields
Order Key
Account Key
ord_key
act_key
Billing Telephone
Number Key
abt_key
Agent Key
act_agent
Project
ord_project
Batch
ord_batch
Customer order
number
ord_cust_or
derno
Thor Technologies, Inc.
A system generated (primary) key that identifies the order.
The key of the account that placed the order. This is a
foreign key that is referenced by the account table.
The billing telephone number for the service requested that
this order would be billed to. This is a foreign key
referenced by the billing telephone number table.
The key of the agent that placed the order for the customer.
Agent information is also stored in the accounts table. This
is a foreign key referenced by the account table. The
act_agent is the act_key of the agent’s account.
An optional customer-supplied field identifying the
customer project that this order is part of.
An optional customer-supplied field identifying the batch
of orders that this order is part of.
An optional customer-supplied field identifying the order
number that the customer is using to identify the particular
order.
Page 18
Xellerate 5.0 Developer’s Quick-Start Guide
Order Content Item Table (sysadm.orc)
The order content item table is part of the request for a specific service. For example: a
calling card or a long-distance number. There is one entry in the order content item table
for every service ordered. The table primarily serves as a link between the account/order
information, service definition, and service-specific information.
Major fields
Type of service
key
tos_key
Package Key
pkg_key
Account Key
act_key
Order Key
ord_key
Order Content
Item Key
Billing
Telephone
Number Key
Order Content
Item Status
orc_key
Service
Identifier
orc_tos_instance
_key
Thor Technologies, Inc.
abt_key
orc_status
Identifies the service that the particular order content
item is an instance of. This is a foreign key referenced
by the tos_key in the Type of Service table.
Identifies the package that the particular order content
item is an instance of. This is a foreign key referenced
by the pkg_key in the Package table.
Identifies the account that ordered the service. This is a
foreign key reference by the accounts table.
Identifies the order that the service was requested under.
This is a foreign key reference by the order table.
This is a system-generated (primary) key that identifies
the order content item.
Identifies the BTN that this service will be billed to.
This is a foreign key reference by the billing telephone
number table.
Indicates the status (Completed, Pending, Rejected,
Suspended, or Cancelled) of the order content item.
Although this isn’t a foreign key reference, the
orc_status should always have an equivalent value in the
sta_status of the STA (Status) table.
Identifies the order content item based on some sort of
unique identifier used by the particular service. For
example, the ANI is used as the service identifier for the
1+ service, while the card number is used for the Calling
Card service.
Page 19
Xellerate 5.0 Developer’s Quick-Start Guide
Service-specific tables
These types of tables may vary from service to service and are not covered in detail by
this document. Examples of service specific tables are sysadm.ani (for the 1+ type of
service), and sysadm.crd (for the Calling Card service). These tables have several
common characteristics such as key columns that are also used in the Order Content Item
table, an identifying key, and several columns containing information about the
configuration of an order for that type of service, such as the card number and pin for the
Calling Card service, or the phone number and carrier for the 1+ service).
Major Fields
Type of service key
tos_key
Package Key
pkg_key
Account Key
act_key
Order Key
ord_key
Order Content Item
Key
Billing Telephone
Number Key
orc_key
Table-specific Key
Varies
Information about
service itself
Varies,
multiple
columns
Thor Technologies, Inc.
abt_key
Identifies the service that the particular order content
item is an instance of. This is a foreign key referenced
by the tos_key in the Type of Service table.
Identifies the package that the particular order content
item is an instance of. This is a foreign key referenced
by the pkg_key in the Package table
Identifies the account that ordered the service. This is a
foreign key referenced by the accounts table.
Identifies the order that the service was requested under.
This is a foreign key referenced by the order table.
System-generated (primary) key identifying the order
content item.
Identifies the BTN that this service will be billed to.
This is a foreign key referenced by the billing telephone
number table.
The key identifying a specific record in the servicespecific table.
This will also vary from service to service. These are
columns unique to that type of service containing
information about the service configuration itself.
Page 20
Xellerate 5.0 Developer’s Quick-Start Guide
8.3. Order Application Data
The following tables are the top-level tables that define how services within Xellerate
function. All orders for a service begin with the selection of a service package that
contains the desired service(s). A specific service is never ordered directly. The service
package contains at least one type of service and may contain several different types of
bundled services. Each service type within a bundled package is given a separate order
content item. Neither the service type or service package contains a great deal of
information. All application data define how orders are processed and grouped under
package and service type tables.
Packages Table (sysadm.pkg)
The package table contains the definitions of the packages that can be ordered in
Xellerate.
Major Fields
Package Key
Package Name
pkg_key
pkg_name
Key identifying the specific package
The name of the package.
Type of Service Table (sysadm.tos)
The type of service table contains the definitions of services that Xellerate provides. The
type of service field does not contain a great deal of information about the service but is
used to group information specific to each process and informs the application what steps
should be performed for the appropriate item.
Major Fields
Type of Service Key
Service Name
tos_key
tos_name
Key identifying the specific service.
The name of the specific service.
Package Service Table (sysadm.pkc)
This table associates packages with the service(s) package. A package generally consists
of one or more services and normally the same service is part of several packages.
Although the package service table does not have a single identifying key, it is the
combination of the service and package key that uniquely identifies an individual record.
Major Fields
Type of Service Key
Package Key
Thor Technologies, Inc.
tos_key
pkg_key
Key identifying the type of service to associate with
the package. It is referenced by the tos_key column in
the tos table.
Key identifying the package to associate with the type
of service. It is referenced by the pkg_key column in
the pkg table.
Page 21
Xellerate 5.0 Developer’s Quick-Start Guide
9.0. Middleware Architecture
The following is an outline of the middleware architecture:
9.1. Object Manager
•
•
•
•
Main point of contact for Client and Server-side objects
Creates and destroys server-side objects
Provides database access for server-side objects
Caches result sets
9.2. Session Manager
•
•
•
•
•
Stores each client session
Stores database connection for each session
Cleans up active objects left by closed client sessions
Checks for dead (abnormally terminated) client sessions
Stores list of active objects for each client session
9.3. Databases
• One database connection per client, created at client startup
• Server-side (whether created for client or server-side use) use same database for
session
• Each database has associated formatter—converts internal storage form of data to
SQL statement form
9.4. Querying
•
•
•
•
•
•
Handled by DataSets on both client and server side (analogous to cursors)
Contains result set data and metadata
Server directly runs queries and accesses dataset
Client has dataset for storage – client database executes queries and returns results
Metadata result sets are cached
Provide facilities for manipulation of individual fields, bulk copy of data, and tracking
of updates
Thor Technologies, Inc.
Page 22
Xellerate 5.0 Developer’s Quick-Start Guide
9.5. Saving
•
•
•
•
•
•
•
•
Handled by DataObjects
Encapsulates one row
Initialized by key value (or group of key values)
Same data manipulation facilities as dataset
Stores internal state (uninitialized, inserting, updating, deleting, locked)
Stores list of all errors encountered
Triggers an event before and after inserting, updating and deleting
Table Data Object
1. Directly extends from the Data Object
2. Specialized for one physical database table
3. Assumes one identifying key
4. Determines SQL operation (inserting vs. updating) from identifying key
5. Uses dataset’s metadata to generate SQL statements
• Link Data Object
1. Directly extends from the Table Data Object
2. Same functionality as Data Object but tailored for tables using multiple keys to
identify a single row.
• Business Object
1. Directly extends from the Data Object
2. Specialized for bundling multiple data objects into a single logical table.
3. Relies on groups of Table Data Objects to perform SQL work.
9.6. Client Side Operations
•
•
•
•
•
Session Object identifies each session.
Client-side objects request server-side peers and bind to them
Hide invocations on server-side objects
Destroy server-side objects after discarded
Dataset client
1. Genuine Dataset
2. Execute Query uses client database to execute query remotely and retrieves
result set.
• Data Object Client
1. Stores associated client-side dataset
2. Upon instantiation, creates server data object and initializes it based on
client-side data.
3. Save and delete bulk-copies client-side dataset to the server, performs the save
or delete and refreshes client-side dataset with server-side changes.
Thor Technologies, Inc.
Page 23