Presentation given on the Belgian OutSystems Community meetup in November 2018 about Service Modules in OutSystems version 11

1. Service Modules
Didier Leroy

2. Definitions
• Server Action: A strong dependency action where everything runs in a single
process
• Service Module: New type of module used to create Service actions
• Service Application: Outsystems uses this term when they talk about a
application to manage all of your Service Modules
• Service Action : A weak dependency action where everything runs in
different processes

3. Possible in Service modules
Possible Not possible
Server actions & Service actions Interfaces
SOAP, REST, SAP Javascript , error handlers
Processes & timers Client side logic
Database entities Local storage entities
Session variables

4. Service Action
• Changes take immediate effect
• When a service action is called, OutSystems sends the following information
with the call
• UserId andTenantId : Enables the usage of functions like getUserId() and CheckRole()
• Locale: Enables usage of functions like getCurrentLocale()
• Request Key: Enables the correlation of all logs in Service Center

5. When to use what according to OutSystems

6. Advantages
• Findability: When published Service actions are immediately available for
consumers -> manage dependency window
• Impact analysis: Outsystems calculates the impact of changing the
signature of a Service Action.This helps you decide if you need a new
version
• StrongTyping: Just like Server Actions Service Actions are strongly typed
logic elements.This means you can use entities and structures.
• Security: Service Actions are only accessible from the same environment

7. Disadvantage
• Executing logic thru remote calls can have a performance penalty compared to single
process calls
• Take into account the amount of data that needs to be send
• If connections fail the consumer logic needs to handle communication exceptions
• If a Service Action fails the consumer logic must handle the failure
• A rollback in the consumer will not rollback in the ServiceAction
• A rollback in a Service Action does not rollback the logic executed in other Service Actions

8. Example 1
• Order management using functionality of the Customer service
Order Management
Customer
Server Action:As long as these modules have the same
release cycle, keeping these modules strongly-coupled will
not have negative impacts in the deployment phase, while
having positive impact in the development speed.

9. Example 2
• Your system evolves and an application gets added (also sales department)
Order
Management
Customer
Shipping
Server Action: Both are in the Sales module so they are in
the same release cycle

10. Example 3
• Three modules use the Customer functionality
Finance
Customer
Sales Marketing
Service Action: Because the three modules have different
release cycles the change in development time is less effort
then the required deployment time

11. Demo