Mobile Development Basics
Data in OutSystems
This lesson is part of the Developing OutSystems Mobile Apps course.

Welcome to Data in OutSystems, in this session we'd like to discuss the different
types of data that are available in OutSystems entities and Static entities are
available and they have to have identifiers and certain types of
attributes and they have actions associated with them once we have a
number of entities we can go ahead and begin creating entity relationships and
creating entity diagrams that visualize how those entities are relating. We also
have structures which are complex types and those complex types are held in
memory and they can have entities and other structures and their own
attributes so they can be a conglomerate of any types of data structures that are
available and then we have individual variables because of different times we
need to be able to move or share the data that we have been working with and
variables will go ahead and do that so let's get started looking at some more
of the details so inside of Outsystems we do have the data layer and inside the
data layer at the very top we have the capability of creating our entity
diagrams and we can give them a name and then create whatever type of diagram of
the entities that we have so we can display the relationships and other
types of things. We have entities and entities can be of two types they're
either database entities or local storage entities. So database entities
are stored in the database on the server side and local storage will actually be
storing entities on the devices that were dealing with so when we're dealing
with mobile and we have client devices local storage will have the entities
being persisted on the device itself. Structures are going to be the complex
types that we can keep in memory, and then we do have two other types of data
site properties which are sort of cross application shared sets of settings or
data and different types of resources and that can be a number of other types
of data
but when we're talking about structure data and other types of things we have
our structures are you have our entities and then the entity diagrams help
describe some of that so when we work with data most of the time when we're
defining the data and working with it it's inside of the data tab the data
layer. So how do we begin to create entities well it's fairly simple we can
right-click on entities or we can right-click on database entities and we
can go ahead and ask to add an entity and we just have to give it a name and
once we give the entity a name
it's ready to go. We do have some other variables like is it public which means
will it be shared with any other modules outside of this module and then it
would it be exposed read only so would people be able to read the data but not
updated so all entities have these two extra properties that help us
to find whether or not that will be shared so here we have a customer entity
so once we've created an entity typically we have to give its more
definition and that would be what attributes belong with this entity and
when we define the attributes we give them a name we can give them a label but
in general the most important thing is what type of data is it and will it
be a mandatory piece of data so do we need for the customer absolutely to have
their first name and we may decide that no that is not something that's
mandatory that we have to have now when we select the data types, OutSystems has
a number of different basic data types there's text and phone numbers emails
lots of numeric data, we have bolleans for logic, number of date times and then
we have sort of the binary data of blobs and then we have identifiers is for other
types of entities which will be references that we're going to use so
you can see some examples of all the different basic data types and what the
default values will be.
Now, when we are defining an attribute if we give an attribute a name, OutSystems
will try to infer the type for you
so by default it will give it a text type if it can't figure it out, but if it
can figure out something from the way you have named your entity it will do
that. So if you give some sort of name with account at the end or a number at
the end it will turn it into an integer if you get something like a birth date
that has date inside of it so it will know that it's a date
so here are a lot of different examples of the types of things that if you give
an entity's attribute a particular type of name it we'll go ahead and try to
figure out the data type for you
so the platform's just trying to suggest things that make sense and make us more
productive by doing these things a little bit faster so here we can see our
entity and we've added a number of attributes to it, first name, last name,
email, and phone number, and these would automatically have been typed to email
and phone number but in this particular instance we're looking at the actions
when we create an entity an entity will have an identifier it will have all the
attributes that we go ahead and create for it and then it will have these
things called entity actions and these are the basic CRUD capabilities that are
going to allow us to store and access the information about this entity in the
database. So we can create the customer, we can create or update the customer, we
can update the customer, we can get the customer for update, we can just get the
customer, or delete the customer. So again we have the creates the gets for the
reads the updates and the deletes so normal CRUD type of stuff. This is just another
set of details about those entity actions and the fact that if you're
going to do a create we have to give it the details of what the record is so
it's a client
what are all the client and the attributes that we have and once it
creates it it creates the identifier for that record and it sends us back that
so these are just some descriptions of all the entity actions and the types of
inputs and outputs that you can expect for each one of these entity actions and
when it creates it, depending on what you name the
entity that's what the into the actions will be called so here it's update and
for us it was UpdateClient, GetClient because that's just the naming
convention. So that takes care of entities that shows us that we can go
ahead and create those so what's the difference between an entity and a
static entity and you can see that the icons are different we have a red stripe
down the middle and the name is different so if the entities are being
persisted and that sort of makes sense
static entities implies that they can't be changed and that is what we're
dealing with so when we create a static entity we're going to create a static
entity that represents some set of data and then we're going to create the
instances and we're going to call them records of those types of things
so here we can create a static entity and if we call that static entity
Country and here we're saying okay we're going to have something called Country
and the description is we're going to create a few of the world's countries so
we could go ahead and reference them and you can see down below it already begins
looking for the types of records so this makes a little more sense when we look
inside of the data tab in more detail if we're in a static entity the static
entity will have an identifier and it will have certain types of attributes
but then it has records and what this basically means is that each of these
records will have an identifier with these attributes in it, and then it will
not be able to be changed so when we say it's static these are all going to be
defined and the values of these once they are defined at design time, in
development tim, they will not be able to be changed at runtime, and from what
we just talked about a second ago about the entity actions you can see that this
is static in the fact that the only entity action we have for our Country
is to GetCountry so we can't update it, we can't create new ones, we can't do any
of that because the static entity has already defined the list of Records and
the types of attributes that they have so if you really step back for a second
from a development perspective and you think about this what we've really done
is we've created a set of data they can't be changed but that we can use and
it's sort of a we have a record and some information about it so this is
basically an enumeration that can return on different types of information about
whichever part of the enumerable we select so in this particular case we see
we have Portugal highlighted so when we look down below in the details so this
is one of our static entities records
Portugal is the identifier and then the labels Portugal this is the first record
in the list of Records its active and we have decided to add a country code and
then this will be the country code access modifier so here we have static
entity information that can help us sort of retrieve this type of information
whenever we need it. So if you need enumerations things like that static
entities can be a great way to go ahead and use those so that helps us define
our entities and our static entities but we may find is that one entity may have
some sort of relationship with another entity so it's rare that one set of data
will be enough by itself and a good example here is we may have books and
the books may have been published by some sort of publisher, they will have
some sort of author, so each book has one or more authors, and then an author
may have written one or more books and an author may have more details about
themselves which we call their Biography.
So these are a set of entities that are all related to each other and the types
of relationships that they have are important because all of this data is
very related to one another so it is important that all this data fits
together and it make
sense so how would we begin trying to create these relationships and make sure
that everything is working properly?
Well the first thing we will do is create the entities and we've already been able to
do that but one important thing is we already mentioned it but an entity will
have an identifier so when we going to look at the entity the first attribute
should always be the ID and it's the identifier it always has the red stripe
down the middle and that's going to be the primary key so when we talk about
entities their persisted in tables in the database so this ID is our
identifier it also is the primary key of the author table in the database.
By default the idea is a long integer and it is mandatory and it will auto
number so that we guarantee the uniqueness, and you can change the type
of an identifier so that it doesn't have to be a long integer you can change it
back to integer or text or something else but you do have to manage to make
sure that it's going to be unique so one other thing that's important is
sometimes when you think about creating more advanced data structures and other
types of things you may say that we're creating some sort of table or set of
entities that have a composite set of keys inside of OutSystems we only have
simple primary keys and it will always be the identifier so once we have an
entity and we have an identifier then we have another entity that we want to
create a relationship with and be able to reference the other entity from this
entity, then we're going to have a foreign key and for that foreign key
we're going to need a reference attribute and the reference attribute
has a blue stripe down the middle with a little arrow so here if we look at the
books, the books have a Title, Publication Date in addition and the books have a
PublisherID so there's a publisher that is an entity and it's identified and we
know where those publishers are we know details about them but all those
publishers have identifiers so we can go ahead and say that this book was
published by particular publisher by including the PublisherID and then we
have the relationship where we can navigate the relationship and get
the information about the publisher of this book. So is mandatory referenced
attributes will be checked by the database to make sure that they are
there so if we take PublisherId and we say it's mandatory
then if a book is created it's going to have to have a PublisherId so it knows
to complete that relationship and if we create some sort of attribute and we
give it a name and we put Id at the end with a capital I and a little d it will
always go ahead and look for an entity and create the entity type if we want
so again it does some nice things to kind of keep everything the way it should be
now once we have relationships between entities. There are different types of
relationships and they will be diagram differently in the entity diagram editor
and they sort of represent different types of things so we said earlier that
the author may have a biography and the author has an Id to define and identify
who they are. When we go to create a biography which may be their picture and
more information about them if we go ahead and change the identifier of the
biography to be the same identifier as the author so we actually say we want to
use the Author Id as our Id for the Biography than what we've done is we've
created a 1-to-1 relationship these two entities are sharing the same identifier
and sometimes the Biography entity is referred to as an extension and entity
so the Author is the original entity Biography is extending it and adding
these extra attributes to that entity so the good news here is and we
can go ahead and create these relatively easily by creating new entities and
giving it the ID of the thing we're trying to extend
so those are 1-to-1 relationships. Sometimes we don't have just 1-to-1
relationship sometimes we have 1-to-many so we may have a Publisher that is
able to publish books and the Book identifies who publishes that particular
Book and the Publisher can publish many books so when we say there's a
1-to-many relationship here one Publisher can publish many books so when
we look at the relationship we see the line being drawn and then we see the
connector at the end having these three lines to go ahead and describe that, that
implies the many relationship sometimes this relationship is referred to as a
master-detail relationship and the fact that the detail entity references the
master entity so that we understand, you know, one of these things references many
of the others so that's a 1-to-many relationship and then finally we may
have something that goes one step beyond that which sometimes is referred to as a
many-to-many relationship and what that means is that we may have a Book that
has one or more authors and an Author may create one or more books so we have
a many-to-many relationship between authors and books but there's no way to
be able to create those relationships back-and-forth directly with each other
so what we do instead is we create what is often referred to as a junction or a
reference table so a junction entity or reference table we'll go ahead and
sit in the middle and it will say that there are book authors so there is a
book and we know who the author of that book is and by having this intermediate
table we now know that an Author could be part of a particular BookAuthor and
the Book any book could be a BookAuthor but this BookAuthor there could be
three Book authors for a book and there could be
five books that are related to one given author so here we have a 1-to-many
relationship between Author and Bbook authors we have a 1-to-many
relationship between books and Book authors so when we follow the
navigation we actually get a many-to-many relationship between these
two things so we can go ahead and easily set this up to be able to have
that type of relationship as well.
Now sometimes when we set up these relationships people refer to will do
you have referential integrity so that if I'm referencing another entity what
happens if that entity gets deleted. Do i need to have this entity be deleted
or what happens? Inside of OutSystems we have what we call delete rules, and we
can either protect the reference to entity, we can delete it, or we can ignore
the fact that this has occurred so we wouldn't actually care that the other
entity has gone away so for Protect and we would basically say don't allow
the deletion of reference to entities unless nothing else points to this
entity so if we had an entity that had relationships to others and those were
still valid then it wouldn't do any of the deletes we could also set it to
Delete which says that if we see a reference density being deleted, delete
all of the other referenced entities that go with it
so this just gives you a way to look at the relationships that you've created
and say are these tightly coupled relationships that need to exist or not
exist together, or is the relationship a little bit looser and and we can sort of
ignore some of the things that occur. Last, as far as entities and other
types of things there is an entity editor so if we double-click on any of
our entities and we open them up in the entity editor one of the things that's
available is not just the name the description the attributes but indexes
because we know these entities are being persisted in a database these indexes
this index area would allow us to create an index on that table so that we could
go ahead and try to speed up the retrieval of that type of data
that may be there may be a cost to that little bit of an extra writing and
overhead for storage to be able to create these indexes and do that but it
can do a number of other things as well so we could create indexes with one or
more types of attributes and we could ask that to be unique so that we know
there will be certain types of things that we don't have duplicate records
inside the database so it can be very nice by default anytime we reference
some of the others so if we have a Book and it has an AuthorId then we'll go
ahead and have a index for any of the references that we're going to have
because we would expect that we may need to retrieve those and here at the very
end if we had all of these entities and we created all these relationships so we
can see that our Biography has a 1-to-1 relationship with the Author
we have this many-to-many relationship between the authors of the books and
then we have a 1-to-many relationship between the Publisher and the books. So we
can see that all those relationships exist and the little icons tell us a
little bit about those relationships and then the Delete rule also shows up in
the color of the links so here we might say hey when the author gets deleted,
deleted biography as well because it would make sense to have a biography
with no primary author if it's a dark link then we're going to protect it and
not do it and if we have a light gray link and we can go ahead and ignore that
if the Publisher disappears the Book would still exist and we may or may not
remember who the publishers and that's probably okay and if we deleted all the
books the Publisher may not care so we still want data about the Publisher and
that make sense so entity diagrams can show us a lot of information not
only about the entities but their relationships and the types of delete
rules that we have enforced upon them.
So that does a lot with entities, we've described how we can create entities and
Static entities how we can create all these relationships but occasionally
we're going to need data that's coming from different places but we only needed
it in memory we don't actually need to be persistent to the database and we want
something fairly complex where would this come up a lot of times we use
structures to go ahead and hold onto data that's coming from services and
whether their web services or restful services we want to be able to hold the
data that's coming in that data may be complex and have a very rich structure
so we don't want to limit it to just basic types like the entities have. So we
can come down inside of the data tab to the structures area and we could say I
have a CombinedCustomerInfo structure that has information about the Customer
information, about the Country and some other attributes and when you see the
small green icons that look like the entity icon it's a complex type and it
can refer to the actual entity type and then we have these, these look like the
attributes from the entities so these are just attributes of a structure and
we could go ahead and create these and these will have a basic type so our
structures can have multiple structures or entities inside of them as well as
other attributes so it truly is the most flexible way to create a data structure
definition inside of OutSystems now once we have all of our entities and other
types of things we may need to use some of this information in either the
screens that we're creating and some of the actions and the the logic that we're
creating so we need to have variables and we can create variables to store
different types of information variables can either be basic types or compound
types and once the variable exists the variable will have a scope so the
variable will be attached to something and that will be the scope in which the
variable lives so it's fairly easy to think about when we begin saying okay
let's say we have an action
we have a server action so we have a set of logic that's going to run on
the server and inside the server action it needs an input parameter so that will
create a variable for us and that will be the input variable will also have the
ability to have output parameters so all those output parameters will have some
sort of output variable and if we need variables that exist during this actions
logic being run but it's not an input and output we can just add a local
variable so variables are there once we create a variable the variable will need
a type so we can go choose one of the basic types or if the variable is going
to be holding the information from an entity it could go ahead and hold an
entity or a structure so that it has that type of of information. So inside
this section we've covered a lot, we've talked about entities and Static
entities, we've shown all the relationships that can occur, we talked
about structures and variables. So this is more about defining and making
sure that we have the data that we need where we need it at different times were
then going to have to reference this data and be able to retrieve it
so we're going to discuss that in a separate section but hopefully hear
you've got a feel for the types of data that we can persist types of day that we
can have in memory and how we deal with variables so that you'll be able to
retrieve information from entities and other things because they've been
defined well and you know what they are.