Welcome to the application and modules session. In this session the topics we'd
like to cover are describing what an application in OutSystems is and we'll
focus on the types and the types of applications can have modules, and then
we'll also talk about modular programming and some of the benefits
that it has and how we use it inside of OutSystems to share and reuse
different types of elements. So inside of OutSystems 10, applications can either
be Web applications or mobile apps but they can't be both.
So you have to choose one or the other because the interaction patterns for
each are a little bit different.
These applications are allowed to contain one or more modules and the
modules themselves contain elements and the elements could be something as
simple as entities and part of a data model, logic and different types of
actions and methods, as well as user interface elements. But applications are
the basic deployment unit for the OutSystems server, so when we go to
deploy something inside of OutSystems we deploy applications, we don't deploy
modules, and those applications
become the key thing that get deployed and those applications when
they're deployed will be versioned and tagged and that will allow us to track
them and manage them a little bit easier. So applications are allowed to be
deployed and once they're deployed they're accessible, but there are times
when we build an application and some part of that application is sort of a
core component that is reusable. So applications are allowed to access and
reuse elements from other applications and one of the ways we can do this is
that we can allow applications to have different modules and some of those
modules can make some of their elements public thereby sharing them and that
would allow them to be used by other modules. When a module makes something
public the elements that are referenced inside of another app we say that that
creates a dependency from one application
to another. And officially it's creating a dependency from one module to another
but since those modules live inside the applications and the applications are
what are being deployed, then there's a dependency between the actual
applications. So let's think about this and look at something a little more
concrete because there are a lot of ideas there. There are different types of
application types so when we go to create a brand new application in OutSystems
we'll choose Web or mobile and once we choose our type that sort of
gives us the interaction pattern that I mentioned earlier, so if we choose a
Web app the Web app has server-side logic it has database persistence and entities,
it has a synchronous interaction pattern where the pages called server, the server
does a bunch of work and then responds back, and that is the request-response
pattern. Now when we think about moving to a mobile application, the mobile
application is going to be running mostly in the device and that means that
there are their server side logic and client-side logic and that client-side logic
runs in the device, that client-side logic could be interacting with local
data that is stored locally on the device or it could be calling the server
and getting things out of the database. But all of those calls from a screen are
happening asynchronously, so if a screen needs multiple types of data it can make
all of those calls at the same time and whenever the data comes back we would be
rendering it on the screen. And that means that what's happening inside of
the device, the client-side logic and the data, needs to be reactive so if
something changes and it changes locally in the device it should be able to
update and it shouldn't have to call the server to be able to do that. So when you
begin looking at the different types of applications that we can create, Web apps
are your traditional Web sites and Web pages they do request-response, they
can be a little more dynamic because they can have AJAX capabilities inside
of them,
but our mobile apps are mostly JavaScript and other types of things
running on the client device, so we call them reactive and in reality they're
single page applications and those single-page applications are using React
JavaScript to go ahead and be able to change things locally as fast as
possible.
Now when we choose our application type if we choose one or the other,
there will be the application created and then it will say what type of module
do you want.
So if we chose a mobile application then we would have a choice of a mobile
module but they're actually just four types of different modules so if we
chose Web there would be a Web choice here but here we have mobile and then
there can be a blank module or an extension module, but when the
application gets created it automatically creates a module gives the
module a name, whatever that name might be, and then we have to choose the type
of module that we wish to create. Applications have to have at least one
module that's why one is here to start with, because if you delete all of
the modules from the application the application has no behavior, no
functionality, and it it doesn't really make sense to have anything like that.
Now when we think of the different module types the Web module will contain
all the basic resources for a Web application and that Web module could
have templates that are going to dictate the look and feel of the Web site.
A mobile module will have all the basic resources for mobile apps and that will
include either the phone the tablet or what we call the universal type template.
If we have a blank module, the blank module will actually be an empty or a clean
module that doesn't have any pre-defined behaviours, any types of interfaces, so
there's basically nothing in the module at all, which is a good thing. And then
the extension module would be opened in Integration Studio and this is a
particular type of module that allows us to extend the platform and integrate
with other systems. So this is one of those where we may have an extension
module that gets us data
out of an external database, that allows us to use Java or .NET code depending on
our server type, so those extension modules are available as well. So we have
applications and they have modules inside of them, so why do we have this
modular programming capability? Well, in general it's a software design technique and
what it allows us to do is create independent and then replaceable or
reusable modules and probably the most important piece there is "reusable".
If module 3 has some really good functionality and module 1 wants to
use it should be able to do that. Same thing here: if module 2 has some
interesting capability maybe module 3 and module 1 want to be able to use it,
so each module can contain different types of elements and if any of those
elements would be reusable, we'd like to go ahead and be able to do that.
So inside of OutSystems
how would we do that? Well, if we have a core module and that core module has
certain types of data and we'd like that data to be reusable in other places, we
can come down and actually make it public and for entities and things like
that once they are public we can decide whether they should be exposed read only
or whether they should actually be allowed to be updated as well. But when
we look inside of a module, data could be made public, different types of logic as
far as actions and roles, and then some of the web blocks or web screens could
also be shared. So if we were going to share some of these, how would someone
else be able to find them?
Well, from the menu in the the toolbar area, we can find reusable elements by going
to Manage Dependencies, and when we go to Manage Dependencies it will list all of
the different modules that we have access to. So depending on our role and
who has granted us access to some of these other things as far as whether
we're a developer role or other types of roles, it will give us the list and these
are currently the modules that have some sort of public element
that is available. We could go in and say oh well the Employees module seems
interesting i'd like to go ahead and be able to get to the EmployeePictures so
once we choose a module it will show us what inside of that module is being made
public and in this case it's just one entity, the picture. We could go ahead and
select that and then we'd be able to use it. Now you can also see here that there
are a bunch of little blue circles that kind of look like a recycle thing, and
what that's saying is that we had previously looked at these modules and
potentially grabbed some of the elements that we wanted to use and since we did
that, these have been updated, so we might need to refresh updated references when
something changes in the producer who's producing it and making it available,
where the consumers consuming it. We want to make sure that we have the latest and
greatest information, so that if they published their module, we'll be able to
have what we need from that. There is this nice new feature in this version of
the platform, so in OutSystems 10 we have Refresh All that allows us to say:
"you know what, for any of the modules that I'm using go ahead and refresh them
all and bring all of the things into this particular module", and that speeds
things up, because a lot of times we spend time going through all four of
these if we needed them, and updating each one. So just as an example, Field
Services is an interesting application that is one of our mobile apps that is
targeted toward a tablet and it has a lot of different capabilities. Inside
that application itself it has a module that does all of the logic and work, it
has another module for a bunch of assets and data, and then you can see here that
it has dependencies so these are all modules from other applications and it
is showing us all the applications that we're currently dependent on. So, you know,
in this case Field Services is a
very complex application that's using 12 different other things as far as
components that it's reusing. Things like Google Maps, the signature pad, some of
the Silk capabilities and the different types of plugins are all things that
Field Services uses. So this concept of the creating components that might be
reused in multiple places and having a highly reusable component, is a really
good idea.
Now there are some common patterns for doing this. If we're going to make things
reusable sometimes we take groups of screens or blocks, sort of user interface
things, that might be related to multiple applications or processes and we'll go
ahead and put all of those screens in one reusable module. We can also do
integration. So if we're integrating with an external system like Salesforce or
something else we could go ahead and create that integration, place it inside
of one module, and then anyone who needs to be able to use that integration would
be able to quickly import and consume that and be able to get the things that
it needs. We can also go ahead and encapsulate different types of business concepts.
So before we saw the concept of an employee.
Well if we wanted to make an employee a core business entity then we could go
ahead and take all of the data and logic revolving around employees, put it
inside of a particular module and then make that module available. And then a
lot of times we have just truly reusable concepts: maybe utilities or small
technical features and and we could go ahead and use those. So these are
different types of modularization patterns that that can be very
interesting.
So in general the definition that we had here for modular programming came from
Wikipedia, and inside of OutSystems we do follow these modularization patterns
and we have something called the Four Layer Canvas that is part of the
architecture of OutSystems applications. So we sort of have a set of best
practices that tell you how you can architect your application
and if you want you can go ahead and read this particular brief on how
you can approach that and and what it takes to do that. So in this session we
wanted to talk about what an OutSystems application is and the fact that it has
modules. Those modules can be of different types and in many cases we
want to be careful about how we create those modules and what we put in them
because we're using modular programming and we want to be able to share and
reuse those elements, and as we're doing that there are different patterns that
we can go ahead and follow and when we follow those patterns then we'll be able
to manage the dependencies and do a good job of making our applications more
flexible and it also give developers a little more flexibility to to go ahead
and reuse things and build things in smaller components and groups. So talked
about a lot of things for applications and modules that will set us up to be
able to understand building larger applications in the future.