Hi,
As a developer, how to make a decision whether to create a server action or service action?
Thanks,
Saicharan
Hello Sai,
Please, read this: https://success.outsystems.com/Documentation/11/Developing_an_Application/Reuse_and_Refactor/Use_Services_to_Expose_Functionality#Exposing_Service_Actions
It will give you a very good insight on the scenarios where a Service Action is useful.
Cheers
Hey Sai,
The name itself suggests the usage. Server actions are more suitable for tightly coupled architecture kind of functionalities where any changes required a refresh at the consumer level too. While service actions are more for the service oriented architecture or the loosely coupled architecture. Let me know if you are looking for any other specific details. You can always Google for articles around these for better understanding.
Hope this helps!
Cheers,
Tushar
Hi Sai,
I like this decision table to decide what type of service to use:
Regards,
Daniel
Can someone please explain what does domain mean in this context?
You may understand more about domain in https://success.outsystems.com/Documentation/Best_Practices/Architecture/OutSystems_Domain_Driven_Architecture/Domain_Driven_Design_with_OutSystems
Server Actions / Service Actions / Integrations
Figure Showing Server Actions as PublicServer Actions as Public or Service Actions is completely depends on the scope of usage of the module you are creating.
1. Server Actions: If the action scope is limited to that module sure you will create Server Action. But If you want to use that action inside other modules, then you have to ask yourself
Q1) Is this action will be used by few modules only?
Q2) Can this action will be used by many modules in future?
If you are sure that, the scope of usage of this action is limited to few modules, then you can create the server action and make it as public. But if you have plan to make this action available for many modules, then don't go for this as it will create a strong dependency and it will create a problem for you during the deployments in future. As due to the strong dependency you have to deploy the all dependent modules/applications with it.
2. Service Actions: It is an API, which can be used by any module in OutSystems Only. It has some development efforts, but you need to check the usage of this action. As I said earlier, if your scope of usage is wide, then go for this.
3. Integrations: It is also an API, which can be used by any module in OutSystems as well as it can also be consumed by external applications (not developed within the OutSystems as well). It's name Integration itself define its usage, which means you can use this option if you want to integrate with other systems.
A server action is a type of OutSystems action that runs on the server-side. It contains server-side logic and can perform tasks such as data retrieval, manipulation, and validation. Server actions are typically used to implement business logic and are called from client actions, screen actions, or other server actions.
A service action is a type of server action that is exposed as a web service. Once you have created a service action, you can call it from other actions or screens within your application. This allows you to reuse the same logic and functionality across multiple parts of your application, making it easier to maintain and update over time.
Sangeeth Rs
Dear Sangeeth,
Service actions cannot be used to integrate with other systems or expose to other applications.
If you want to expose for other applications, then you need to use Integrations.
Service actions scope is only limited to OutSystems Platform.
The Server Action logic is executed just as if it is defined in the consumer module, running in a single process with the same request and transaction. Each time the implementation of an exposed Server Action changes, the consumer modules must be refreshed and republished to start using the latest version.
Service Action is a REST based remote call to another process, but its usage is very similar to public Server Actions. Exposing a Service Action generates a weak dependency from the consumer to the producer module, in a loosely-coupled way. Each time the implementation of an exposed Service Action changes, that change takes immediate effect in the consumer modules.