of this stage you should be familiar with the following
Data-element, Data Types, Flow, Slot, Display
Data-element, Ancestor Reference, Reserved Names,
Retrieving user input from the display, Storing
data in a database table.
Useful process templates:
stage you will model some basic application logic - retrieving
the requisition description entered by the user (through the popup
form) and saving it in a database table.
This stage’s modeling should
be performed in the Tutorial 2-3 project, you
imported at the
end of the previous stage.
previous stage we learned how to model a form for simple data
entry. We mentioned that one crucial thing was missing – saving
the data entered by the user.
let's model the saving of the requisition’s description
when the user clicks the Submit button.
above, Tersus modeling employs a zoom-in technique in which
application logic is defined "inside" the display element
which invokes it. In our case, saving of the requisition’s
details should be performed when the button is clicked, so it will
modeled inside the Submit button.
Zoom into the Submit
button by double-clicking on it in the model editor (or in the
now define a data structure to store the details of a
Select the Data
Types/Database Record template ()
and drop it into the button. Name it Requisition.
A data structure is a
of data items (either “primitives” like a number or a
date, or other data structures). Data structures appear in the
as gray rectangles.
You may have noticed a Data
Structure template appearing next to the Database
template in the Palette. The two templates are practically
identical, except for the fact that a Database Record
structure is automatically associated with a matching database
and since we would like the Requisition data to be
the database, as we will see later in this stage, we are
basing it on
a Database Record.
Submit model should look similar to the following:
should define the fields comprising the data structure. To insert
data elements into the data structure, we simply drag the
data types (Number, Text, etc.).
Select the Data
Types/Number template ()
and drop it into the Requisition
data structure. Name it Id.
Select the Data
Types/Text template ()
and drop it into Requisition
as well. Name it Description.
Requisition data structure should look similar to the
data structure now contains 2 fields: Id, which is
to be an automatically-generated unique identifier for each
requisition, and Description, which is a free text
of the requisition as entered by the user.
previously, Id must be an automatically-generated,
unique identifier. It must be unique, because we don’t want any
two requisitions to have the same identifier.
be accomplished by using the Sequence Number template:
Select the Database/Sequence
Number template ()
and drop it into the Submit
model. Name it Requisition Id.
should look similar to the following:
Sequence Number is an
example of a built-in process (action) that generates a new
identifier. A process is something that is being performed.
A process can be a built-in action
provided with the Tersus platform, and accessible through the
(e.g. a basic mathematical calculation), or a more complex
modeled by a user (either you yourself or someone else).
Process modeling is the major
activity required for creating a solution (a solution is
display models, data models and process models).
process (in our case Sequence Number) generates some
(the unique identifier), the output needs to “exit” the
process in order to be used by another process or populate a field
a data structure. An Exit slot is modeled as a gray
that appears on the frame of the process model.
There are two major types of
Slots: Triggers that receive data when a
(discussed later), and Exits that expose data
generated by the
process while executing.
Sequence Number template outputs the unique identifier it
created through the predefined <Next> exit.
we still need to pass this generated identifier from the
<Next> exit of the
process to the Id field of the Requisition
structure. To do this we shall use a Flow.
Select the Flow
at the top row of the palette, click on the <Next>
exit slot ()
of Requisition Id
to specify the Source,
and then click on the Id
field in Requisition
to specify the Target.
An arrow should appear linking the slot with the field.
While using the Flow
the mouse pointer changes to signify whether the current
serve as the Source or Target of a flow
Submit model should now look as follows:
Flow is modeled by an arrow between two model elements (Source
and Target). A Flow
defines the relation between the Source and
Target, in two ways:
Execution: When should each process be executed (and
on what conditions).
Flow: When and how are data items passed.
we've stored the automatically generated identifier in the
Requisition data structure, we need to store the Description
in the same data structure – after all, this is the real
information we are interested in. To accomplish this we shall
a new type of element in the model called a Display Data
Display Data Element is an alternative representation of a
Display element (and its sub-elements) as a data structure.
It's main purpose is to provide access to the contents of the
so that it can be read from or written to.
look at the display hierarchy of the popup we are modeling,
which contains a label, a text area, a footer and 2 buttons (see
screenshot of the Display - below left). This is
by a data structure of the popup, which contains data structures
the text area, button and label; the text area contains another
structure for its value (see screenshot of the Display Data
Element - below right).
The order of display elements
the Display Data Element screen shot (above right) may be
from the one you see in your model. The order of appearance is
defined by the order in which the elements were actually
long as all the elements appear (at any order) the runtime
will be consistent with the tutorial.
like to access the contents of the Description
text area, and so we must add to the Submit
button a Display Data Element
that references the Enter New Requisition
popup. Since Enter New Requisition
is the “father” of the Submit
button, we use the Add Ancestor Reference
Right-click on the Submit
button, select Add
Reference from the menu, and select
Enter New Requisition.
Notice that the inserted data
structure has a blue frame (as opposed to the regular black
other elements). The blue frame indicates the fact that the
structure is a reference to another element (the Enter New
Requisition popup), so that as data changes in one the
automatically mirrored in the other.
need to create a flow from the Description text area
within Enter New Requisition to the Description
in the Requisition Data structure. The actual text entered
the user is available through the <Value> data
of the Description text area within Enter New
Use the Flow
to link Enter New
Most display elements contain
default data elements through which they can be manipulated.
data elements are identified with a descriptive name (such as
surrounded by angled brackets (<...>).
what this model does so far:
Requisition Id sub-process generates an identifier that is
passed to the Id field of Requisition, and the
of the Description text area (entered by the user) is
to the Description field of Requisition.
the Requisition data structure has been created and
populated with the relevant data, the data has to be stored in the
database. To accomplish this, we shall use another process
Select the Database/Insert
and drop it next to the Requisition
Insert template includes a <Record> trigger
through which it receives the data structure to be saved in the
Trigger slots are used as the
entry point through which a process receives input data when
the Requisition data structure to Insert, let's
create a flow:
Select the Flow
then click on the Requisition
data structure (anywhere outside the Id
fields) to define it as the source of the flow, and then click
trigger of the Insert
model to define it as the target of the flow.
Submit model should look as follows:
of the last change should be straight forward – the
Requisition database record data structure is inserted as a
new record to the database, into a database table with an
name: Requisition. If the table does not exist in the
database, it will be created automatically by the application
Notice that many slot names
templates (such as Sequence
and Insert in the above screenshot) use a
naming convention, where the name is surrounded by angled
(‘<…>’). These are reserved names on
which template functionality may rely. If a reserved name is
the template may fail or function incorrectly.
requisition has been written to the database, the popup window
Select the Display Actions/Close Window
and drop it into the Submit button.
Submit model has 2 parts occurring in an unspecified order,
one is the Close Window process, and the other is the
processes which saves the requisition data in the database.
is mandatory to specify which process occurs first, because the
order of processes is an essential part of the application’s
logic. In other cases the order in not important, but
it is a good practice to make sure processes occur in a well
order even when this is less critical.
to make sure that the Enter New Requisition popup window
closes only after data has been saved, therefore we should define
flow which specifies that the Close Window process occurs
following the Insert process, and only if insertion was
so, we must first add a trigger to Close Window.
We can do so, either by adding a new trigger slot selected from
palette, or by taking advantage of the fact that Close
a pre-defined trigger which is there for exactly that purpose:
on the Close Window element,
open the Add Element
sub-menu, and select the
The “hidden” Control
trigger, is available due to the fact that the Close
template is implemented as a Prototype.
define the elements making up a given model, and what parts
of it are
mandatory. In Close Window's
case the trigger is not required in order for Close
to function (as demonstrated by
the Cancel button in
our popup), but in most use cases (such as the one we have
implemented here) the trigger is needed, and so it is
provided as an
optional element of the Close Window
should be noted that the other templates are also
as prototypes. For Example: Insert's
prototype includes a “hidden” exit, <Duplicate>,
which is useful in cases where the record to be
inserted has a
duplicate key, in our case, if the Requisition data
contains an Id which already exists in the database.
this will never occur in our model (we are generating a unique
using the Sequence Number template), the <Duplicate>
exit may remain “hidden”.
is important to point out that all
elements available through the Add Element
sub-menu are there for 'shortcut' purposes only. Each
actually be created manually (in the specific case
that is by
dragging a trigger from the palette onto Close
and naming it Control),
and will work just as well.
to close the window only after the record has been inserted to
the database, i.e. when Insert is successful and exits
the <Inserted> exit:
Select the Flow
tool to link the <Inserted>
exit of Insert
to the Control
trigger of Close Window.
You may have noticed that the
Insert/<Inserted> trigger in the preceding
has been moved from its default position. This has been done
the model more “readable” to the modeler, and has no
effect on the model’s functionality.
the application in the browser:
Click the Launch the
application toolbar button.
Try entering requisitions.
stage we still cannot see the content of the database to verify
the requisitions have been successfully stored in it. We will
If you wish, you may use an
external tool (usually provided by the DBMS vendor) to verify
the Requisition table has been created in the database
view its content.
sample project Tutorial 3-4 and use it as the basis for
the next stage of the tutorial.
For a reminder on how to
sample project, see the Importing a Sample Project
the end of Stage 2.
project contains all the functionality modeled thus far.
project also includes additional functionality, as follows:
How to Model
fields to the Requisitions table for future
Add a Date
field (drag the Data
Add a Status
field (drag the Data
default value (today's date) to the requisition's Date
Drag the Dates/Today
Define a flow from Today/<Today> to
default value (New) to the requisition's
Drag the Constants/Text
Name it New
Define a flow from “New” to
completed the modeling of the logic performed behind the scenes,
retrieving user input and saving it in the database.
now proceed to Stage 4,
in which we will implement a table display of all the
requisitions stored in the Requisitions table.
to open the live project in a
For best results, use the Firefox browser..