Ebase Entity Types
This
document provides an overview of the different entity types that can be edited
with the Ebase Designer. In the designer tree, these entities are grouped into
the following main categories:
·
Business Projects
·
IT Elements
·
Lists
·
Presentation
·
Workflow
·
Integration Server
·
System
The following
descriptions provide a brief summary of each entity type. Click the link
against each entity for further information.
A project
consists of a number of related forms, scripts and messages. Important aspects
of projects are:
·
scripts and messages within a project can only
be referenced by forms in the same project with the exception of GLOBAL scripts
·
Designer project is the entity that is protected
by the security system i.e. if a designer has read/write access to the project, he has read/write access to all the forms, scripts
and messages within the project.
Components can be created in the
special GLOBAL project. These represent pieces of form functionality that can
be shared by all forms. See Component Concepts.
This is the
central entity within the Ebase system and is made up of pages, controls,
fields, tables, texts, events etc. It can contain references to all the other
entity types depending on the functions performed by the form. See Form Editor.
A script is the Ebase programming entity. Scripts can be executed by the system when the event with which they are associated occurs. See Event Processing and Script Command Syntax.
A message
is a language dependent text, usually an error or warning,
that is sent to the user under the control of a script; once displayed,
the message disappears. The most common use for messages is for validating user
input. See Working with Messages.
A Business View is a lightweight entity and is merely a way of packaging together all the external resources that a form can access. In the Ebase Designer, a form's business view can be specified by clicking the Form Properties icon. (See Working with Business Views for more information).
All external
resources share a mapping layer where resource fields are mapped to form
fields. See Understanding
Integration.
Represents a single SQL statement that can be issued to any
relational database. Typically reading and writing database data. See Working with Databases.
Represents a call to s stored procedure and can be issued to any relational database that supports stored procedures. See Working with Stored Procedures.
Provides the ability to read and write XML documents and to map elements from the XML document to form fields and tables. An XML resource includes a number of adapters that provide specific XML functionality:
See Working with XML Resources.
Provides the ability to call a Web Service and map the request and response documents to form fields and tables. This resource is an extension of an XML resource.
Represents a single email message that can be sent. See Working with Email.
Represents a message that can be read/written to or from an MQSeries message queue. This includes the possibility of waiting for a response message. See Working with MQSeries.
Provides the ability to populate an Adobe Acrobat PDF form with form field data and print via a PDF. Note that printing resources can only be used with existing PDF forms. Ebase provides alternative printing options using print forms. See Working with Printing Resources.
Provides customers
with the ability to write their own external resource to integrate with other
external systems.
See Working with Custom Resources.
This entity
is detached from all the other entities. It represents a connection to a
database and is used by database resources, stored procedure resources and
dynamic lists. The database editor within the Ebase Designer contains an import
function to automatically configure database resources from the metadata of the
database system. See Working with
Databases.
These provide the ability to provide
unique document ids and are typically used when creating new documents. See Working with Sequences.
This is
very similar to a database resource in that it represents a single read SQL
statement. In this case however, the results of the SQL are displayed to the
end-user as a list. When the end-user makes a selection from the list, other
columns from the database can be automatically read into the form. The main
difference between dynamic lists and database resources is that dynamic lists
are much simpler to use and require no script programming. See How to use Dynamic Lists.
This represents a simple list of data which is entirely static or rarely changes. The data values of a static list are entered by the designer using the static list editor. Static lists are less flexible than dynamic lists but are much easier to use. Entries within a static list are language dependent. See How to Use Static Lists.
A
presentation template can be thought of as a “skin”. Each form is linked to a presentation
template which provides default links to Style Sheets
and default styling properties. See Presentation
Templates.
Represent the ability to create CSS style sheets. These are then linked to forms via a Presentation Template or directly to form pages. Class definitions within the style sheets can then be linked with controls and other visual form elements. See Style Sheets.
Provide master page templates used
by print forms.
Provides entities used by the Ebase
Workflow module. See Introduction to
Workflow.
Provides entities used by the Ebase
Integration Server module. These provide the ability to create and publish Web
Services to be called by external applications. Eac Web Service calls an Integration Service which is similar to
an Ebase form. See Ebase Integration Server.
Provides internal Web Services used
internally by the Ebase system.