Hello and welcome to Actions and Code Reusability, where we will be talking
about how you can organize your code into actions to allow it to be called
from multiple places, what statements exist in OutSystems for code flow
control and branching and how outputs of actions are affected by this very same
code branching. The way you can create your code so that it is reusable is
through actions. Now you already know screen actions, that's where you have
implemented behaviors that are very specific to the screen, but there's also
user actions where you can define logic that can be called from any other action.
When you create an action you can define it to have any number of input
parameters and their respective types as well as output parameters. Should you
want to call your code from an expression you can flag it to be a
function, but then you'd need to make sure that it only has one output parameter. So,
what is an action? An action is a sequence of statements that are executed
in a certain order. An action flow always starts with a start node and
can end in an end node and that's normally how you end it. In case you're
implementing a screen action it can actually finish in a download or a
destination. It's possible to have sub flows inside an action flow for
exception handlers and we will cover this in a different lesson. Now one of
the most common statements that you will find in an action flow is an assign
statement. An assign statement, as its name indicates allows you to assign
values to variables. Inside an assign statement you can actually have several
sub statements and they're executed from top to bottom and the OutSystems
platform gives you a few accelerators when you need to bulk assign attributes
for example of an entity to another entity. It's worth noting that assignments
in the OutSystems platform for most data types is done by value. The exceptions are
lists, binary data and objects which are done by
reference, meaning that any changes that you make to the source will be visible
on the target of an assign at a later point. If you want to simulate a by value
behavior on the list, if you really want to duplicate the list and detach it from
the original, use the ListDuplicate system action. Now, a simple action can be
just a direct sequence of other action calls.
However, in most scenarios, you will need to make decisions and branch and do
different behaviors depending on certain conditions. So what kind of mechanics
does the OutSystems platform give you to branch your code? The simplest one is
the if statement.
The if provides you with a condition that is evaluated at runtime and
depending on what it evaluates to, true or false,
it takes one branch or the other. The switch statement behaves very much like
a chaining of if statements. On the switch you define a set of conditions
and if the condition 1 is fulfilled it takes the branch for condition one, if
condition 2 is fulfilled it takes the branch for condition 2, otherwise it
takes the remaining branch. And finally, there's the for each statement that
allows you to iterate through any list and execute code on every record of that
list. As long as the list has items, the cycle branch is followed and upon
executing your custom code it should come back to the for each node. After the
list is deplenished, the other branch is taken and the for each exits.
Please note that the for each is an iterator over a specified list,
it's not a generic while statement. Should you want to implement a generic while
behavior, just use the if statement as its shown over here. If the condition is
true, you take your action otherwise you bail out, therefore implementing a non
list dependent loop. It's important to clarify what impact branching code
execution has on the outputs of action calls. If you assume
that every single of these actions has got one output parameter called out,
please note that the outputs inside of a particular branch are only visible while
you are in that code branch. As soon as you rejoin a common branch, these will no
longer be visible. So in this particular case, the output of ActionLeft is not
visible in the AssignRight
or AssignCommon. The output of ActionRight in turn, is not visible
in the AssignLeft or AssignCommon. ActionBefore, since the compiler knows has been
executed at all points, it will be visible on all the assign statements
that you see here and finally ActionAfter that's executed when the flow is
rejoined, is only seen in the very last assign. While we have been focusing on
the base OutSystems language where we write code using fairly atomic code
statements, the OutSystems platform actually contains its own business
process visual language that enables the design of fairly high-level business
processes and workflows. On the right hand side of the slide you can see an
actual BPT flow example where a few automatic activities like assigning a
reviewer work together with the human activity where this reviewer will need
to check some credits to make a decision on every single loan application that
comes into the system. These asynchronous activities in turn use the
base OutSystems concepts and language we've been talking about, providing a
seamless experience to the developer while using Service Studio. Since the BPT
language is actually a domain of its own we will not cover it at all in this
course but if you want to know more please check the dedicated online course
by following the link at the bottom of the slide. And that's it for Actions and
Code Reusability. Hope this was useful, see you guys in the next lesson.