Service Actions
•Download as PPTX, PDF•
3 likes•2,158 views
The document discusses service actions in OutSystems and their advantages over server actions. Service actions provide internal REST methods that have benefits like public actions such as findability, security, and strong typing, but are only accessible within the same OutSystems environment. They allow changes to producer logic to immediately impact consumers through weak dependencies. The document provides examples of how to design service compositions and handle errors across multiple transactions. It also uses a hypothetical scenario of inviting local residents to a store opening to demonstrate how service actions could be implemented versus server actions.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Service Actions
Similar to Service Actions (20)
More from OutSystems
More from OutSystems (20)
Recently uploaded
Recently uploaded (20)
Service Actions
- 1. | Service Actions Service Actions Trick or treat?
- 2. | Service Actions| Service Actions Rui Coutinho Architecture & Development Domain Expert @ in rui.coutinho@outsystems.com /rucoutinho
- 3. | Service Actions Session Goal That you learn more about Service Action.
- 4. | Service Actions Personal Goal Present what is probably the most boring NextStep topic… without the audience falling asleep!
- 5. | Service Actions Dependencies Back to basics
- 6. | Service Actions What is a Dependency? Whenever a module uses an element that is defined in another module.
- 7. | Service Actions Dependency representation Used in OutSystems architecture designs. Consumer Producer Consumer depends on the Producer We have two type of dependencies
- 8. | Service Actions Strong Dependency In runtime, producer logic is executed as if it’s defined in the consumer module. Consumer Producer Strong Changes in the producer only take effect after republish the consumer.
- 9. | Service Actions Weak Weak Dependency In runtime, the consumer module only needs to know the signature of the element to be able to reuse it. Consumer Producer Changes in the producer take immediate effect in the consumer.
- 10. | Service Actions| Service Actions The strong impact of weak dependencies
- 11. | Service Actions Elements that are weak dependencies OutSystems 11 introduced Service Action, and made improvements on existing elements.
- 12. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Impacts on architecture framework Let’s revise the canvas.
- 13. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Service Actions Service Actions provide services to OutSystems applications.
- 14. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Screens Screens used to be strongly referenced, meaning that screen navigation caused side references.
- 15. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Screens Screen navigation is the main reason of existence for the Orchestration Layer.
- 16. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Screens B EU1 A X EU2 C Z Screen navigation is the main reason of existence for the Orchestration Layer.
- 17. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Screens B EU1 A X EU2 C Z Screen navigation is the main reason of existence for the Orchestration Layer.
- 18. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Screens And in OutSystems 11? B EU1 A X EU2 C Z
- 19. | Service Actions Foundation Layer Core Business Layer Orchestration Layer End-user Layer Bye bye Mr. Orchestration Orchestration Layer is no longer required in OutSystems 11. However, still makes sense for OutSystems 10.
- 20. | Service Actions Service Actions The king of weak references
- 21. | Service Actions .. if you ever used Service Actions! Please raise your hands...
- 22. | Service Actions What is a Service Action? It’s an action that mixes the advantages of loosely-coupled REST API with the RAD capabilities of tightly-coupled Server Actions. Service Action (weak) Consumer Producer
- 23. | Service Actions Making it simpler It’s an internal REST method, that has the benefits of public actions. Consumer Producer Service Action (weak)
- 24. | Service Actions Making it simpler It’s an internal REST method, that has the benefits of public actions. Consumer Producer ● Same Request Key ● Same UserId and Tenant Id ● Different DB Transaction ● Different Session Service Action (weak)
- 25. | Service Actions Benefits Findability Add or remove references Security User Id in context; only accessible from the same environment Access governance With LifeTime, like other public elements Strong typing Entities and structures in signatures Exception handling User/communication exceptions can be caught in consumers Impact analysis Breaking changes on signature
- 26. | Service Actions Service Actions are internal A service action can only be called inside the same OutSystems environment. OS Environment 1 Consumer Service Action OS Environment 2 Consumer External System Consumer localhost
- 27. | Service Actions Outsystems Environment External System Service Actions are internal To provide external APIS, you should continue to use REST APIs. Consumer Service Action REST API Consumer Core Service
- 28. | Service Actions New Naming Convention Anyone can guess what is an OAPI?
- 29. | Service Actions New Naming Convention
- 30. | Service Actions New Naming Convention Consumer Producer_OAPI Producer OutSystems API
- 31. | Service Actions| Service Actions Isolate your service actions
- 32. | Service Actions Must use Service Modules Service Actions can only be exposed inside Service Modules. Note: There is no Interface tab.
- 33. | Service Actions Should use Service Applications Organized service modules, supporting service-oriented architecture. Note: Service Modules may also be created in other types of application.
- 34. | Service Actions Please setup your DevOps model Service application should prevent unwanted references. Reflect that model in your Lifetime teams. Consumer Producer_OAPI Producer Team A No Access Full Control Full Control Team B Full Control Reuse & Monitor No Access
- 35. | Service Actions Don’t implement logic in the API Service Actions should be business agnostic. Consumer Producer_OAPI Producer
- 36. | Service Actions Don’t implement logic in the API Allows to expose the same logic to external systems, by using REST APIs. Consumer Producer_OAPI Producer Producer_API
- 37. | Service Actions Careful design your boundaries Think on the relation between consumer-producer. You Spouse Kids Lover Stuff Design the contract to fit the use case
- 38. | Service Actions| Service Actions OAPI Versioning
- 39. | Service Actions Producer_OAPI Why versioning? Consumer Minimize the impact on consumers: ● Ensure Back-compatibility ● Allow for different development paces ● Deprecate versions elegantly Producer Contract Change Code Change
- 40. | Service Actions Producer_OAPI Code Change Consumer Producer Code Change When the change happens on the internal code, consumers should not be affected.
- 41. | Service Actions Code Change Customer OAPI Consumer Version Id ensures legacy consumers still works, given consumers time to adjust. Customer OAPI Customer CS Contract CS
- 42. | Service Actions Code Change Consumers control when to adopt new version Consumer use a site property to avoid republish Customer OAPI Consumer Customer OAPI Customer CS Contract CS
- 43. | Service Actions Code Change Don’t support too many versions! London Eye Anti-Pattern
- 44. | Service Actions Code Change Force consumers to adapt when version becomes deprecated.
- 45. | Service Actions Producer_OAPI Contract Change Consumer Producer Contract Change Since there is a API change, consumers are affected.
- 47. | Service Actions Contract Change Take effect immediatly? Break the contract. Use impact analysis for broken. Yes Clone existing Service Action. Give consumers time to catch up. No
- 48. | Service Actions Avoid Temptation Input as generic text seems a great way to avoid contract changes...
- 49. | Service Actions| Service Actions Service Composition
- 50. | Service Actions Service Composition How to handle multiple transactions?
- 51. | Service Actions Happy Path Travel Planner Book HotelBook Flight Rental Services Flight Services Hotel Services Rent Car
- 52. | Service Actions Travel Planner Harsh reality... Book HotelBook Flight Rental Services Flight Services Hotel Services Rent Car Undo Flight Undo Hotel User Exception ! Consumers should not have to worry about complex exception handling
- 53. | Service Actions Abstract complexity Travel Planner Transaction is handled by a centralized same service, reusable by other consumers. Booking Services Undo Flight Undo Hotel User Exception ! Rental Services Flight Services Hotel Services
- 54. | Service Actions Happy Path Travel Planner Reissue online Ticket Change Passenger Passenger Services Flight Services
- 55. | Service Actions Harsh reality... Travel Planner Reissue online Ticket Passenger Services Flight Services Undo Passenger Info User Exception ! Consumer must keep track of all rollback information... Change Passenger
- 56. | Service Actions Orchestration service Travel Planner Flight Support Services Passenger Services Flight Services Trade off weak/strong coupling to avoid multiple transactions.
- 57. | Service Actions Theory into practice Let’s follow an example
- 58. | Service Actions Image your company is opening a new store... … and marketing department wants to invite all local residents to the grand- opening! Business Marketing IT
- 59. | Service Actions Use Case “Forget email invitation, it’s too impersonal! Marketing Let’s invite everyone using the good old-fashion letter!”
- 60. | Service Actions Requirements Business “Let’s build something awesome!
- 61. | Service Actions Requirements “Let’s go for MVP...” ITBusiness “Let’s build something awesome!
- 62. | Service Actions Architecture Design Connect to external service, that provides postal code information. Postal Code Provider REST Postal Code IS
- 63. | Service Actions Weak? Architecture Design Store Backoffice Postal Code Provider Strong? REST Shall we use Service Actions? Or Server Actions? Let’s explore both scenarios... Or Postal Code IS
- 64. | Service Actions Multiverse Theory I hope you believe in the existence of parallel universes.
- 65. | Service Actions Multiverse 1 Multiverse 2
- 66. | Service Actions Service Actions Server Actions Multiverse 1 Multiverse 2 Store Backoffice Postal Code IS Postal Code OAPI Store Backoffice Postal Code IS
- 67. | Service Actions Service Actions Server Actions Multiverse 1 Multiverse 2 MV2 Store Manager (Strong) MV2 Postal Services (Strong) Store Backoffice Postal Code IS MV1 Store Manager (Weak) MV1 Postal Services (Weak) Store Backoffice Postal Code IS Postal Code OAPI
- 68. | Service Actions Service Actions Server Actions Application is live
- 69. | Service Actions Service Actions Server Actions Incorrect implementation Results from 2 countries ? I only have stores in Portugal!
- 70. | Service Actions Let’s make some magic 1. Contract Change ■ Add mandatory input
- 71. | Service Actions Service Actions Server Actions MV1 Store Manager (Weak) MV2 Store Manager (Strong) MV1 Postal Services (Weak) MV2 Postal Services (Strong) Store Backoffice Postal Code IS Postal Code OAPI Store Backoffice Postal Code IS Add filter by country code
- 72. | Service Actions Service Actions Server Actions Effect in Development Publish, and do not refresh consumers
- 73. | Service Actions Service Actions Server Actions Platform warnings
- 74. | Service Actions Service Actions Server Actions Effect in Staging
- 75. | Service Actions Service Actions Server Actions Adapt and republishing consumers
- 76. | Service Actions Let’s make some magic 1. Contract Change ■ Add mandatory input 2. Code Change
- 77. | Service Actions Service Actions Server Actions Code Change Business wants to show the country name instead of the code.
- 78. | Service Actions Service Actions Server Actions Update the private code MV2 Store Manager (Strong) MV2 Postal Services (Strong) Store Backoffice Postal Code IS MV1 Store Manager (Weak) MV1 Postal Services (Weak) Store Backoffice Postal Code IS Postal Code OAPI
- 79. | Service Actions Service Actions Server Actions Change is reflected immediately on consumer. Consumer must be refreshed. Effect in Development Publish, and do not refresh consumers
- 80. | Service Actions Service Actions Server Actions Platform warnings
- 81. | Service Actions Service Actions Server Actions Effect in Staging
- 82. | Service Actions Which one shall I pick? Service Action or Server Action?
- 83. | Service Actions Consultant favorite answer... … it depends!
- 84. | Service Actions Don’t go nuts on Service Actions! Don’t move from dll hell into Service Actions nightmare...
- 85. | Service Actions via Service Actions via Server Actions 85 DB Transactions Development Effort Release Cycle Service Communicatio n Deployed togetherDeployed independently Run in a single processRun in different processes Producers & Consumers relation
- 86. | Service Actions via Service Actions via Server Actions 86 DB Transactions Development Effort Release Cycle Service Communicatio n Simpler logic and faster development Additional logic to handle transactionality and error handling Single transaction Deployed together Run in a single process Multiple transactions Deployed independently Run in different processes Producers & Consumers relation
- 87. | Service Actions Usage Scenarios ● Service oriented architecture approach ■ Self-contained, black-box service for multiple consumers ■ Independent release cycles between service and other applications ■ Independent development teams, with clear ownership Consumer 1 Calculation Engine Consumer 2 Team A Team B Team C
- 88. | Service Actions Domain 2 Usage Scenarios ● Domain oriented architecture approach ■ Communication gateway between different domains ■ Well defined boundaries and “closed” contract ■ Independent teams and release cycles between domains Domain 1 Team A Team B
- 89. | Service Actions Usage Scenarios ● Isolate Technical components ■ Support technical decisions ■ Reusable by many applications Feature Services Consumer 1 Consumer 2 Consumer 4 Consumer 3 Consumer 5
- 90. | Service Actions I want Service Actions now!
- 91. | Service Actions … if you are still using OutSystems 10! Please raise your hands...
- 92. | Service Actions Still on OutSystems 10... Don’t despair...
- 93. | Service Actions ...you can always upgrade to 11!
- 94. | Service Actions In the meanwhile, design for OS11! Expose your internal services using REST API. It’s straightforward to later migrate from REST to Service Actions.
- 95. | Service Actions What is YOUR Next Step?
- 96. | Service Actions Carve out your architecture! It’s time to look above and beyond your current architecture!
- 97. | Service Actions Trick or treat? Treat! “The difference between poison and remedy is the dosage”
- 98. | Service Actions Thank You! @ in rui.coutinho@outsystems.co m /rucoutinho
Editor's Notes
- In the spirit of halloween, let’s find out an answer
- I have 2 big goals for today
- What they are When to use them Advantages and challenges
- If you don’t know this… you are in the wrong room
- Reinforce: Consumer MUST be republish to execute the new producer code.
- Reinforce: Consumer do not needs to be republished → which may result in breaking the signature.
- All other elements have strong dependencies.
- Bottom 2 depends if the service is business oriented (provide Customer info) or technical (provide reference data, such as country codes)
- If you need to navigate for another screen, caused the producer to be included into the consumer. This prevented application independency.
- EU1 unnecessarily inherits this cluster. You actually end up with the same application cluster.
- EU1 unnecessarily inherits this cluster. You actually end up with the same application cluster.
- This is a weak dependency…. applications remain independent
- Now, this doesn’t mean we are going to remove the orchestration immediately and rename the 4LC. You can imagine a hierarchy at end-user level (similar to the other levels) if you need a cross-application portal, This slide is my favorite slide: Some people have difficulty to understand when to use this layer. Most of the architectures have, incorrectly, an orchestration module. I found that people tend to use it just because they think they have to have all layers
- 10:00
- I have to read, it’s quite a mouth full...
- Why it behaves as public action? Let’s see the benefits.
- Why it behaves as public action? Let’s see the benefits.
- Strong typing You can use entities and structures in Service Action signatures. Security OutSystems passes the authentication context from the client session when making the call to a Service Action (UserId and TenantId). Exception handling User Exceptions and Communication Exceptions thrown by a Service Action can be caught in the consumer modules. Access governance Service Actions follow the same governance model as any other reusable element defined by permissions in LifeTime.
- If the REST API needs user Id, that user context must be provided. Service Action already has the user id.
- According to wikipedia...
- Strong connection OAPI → Producer Weak connection Consumer → OAPI
- What are the best practices?
- As you can see, the platform is guiding the developer into a correct architecture. As this module is intended to expose services, it doesn’t allow to create UI elements → reinforces the 4LC principles.
- Service application doesn’t allow to create UI or Library modules. Prevents developers to incorrectly define screens in a application intended to provide services.
- If you create a Service Action, but still allow access the Server Action, people will make mistakes.
- Service Actions technical wrapper to expose core services to OutSystems consumers, keeping core services system agnostic and supporting multiple API versions.
- If you follow this approach, it’s easier to later provide the Producer code, your core code, to external systems.
- Use strong or weak dependencies wisely. Control the information exposed → Design the contract to fit the use case.
- Contract change There is a API change, consumer are affected Code Change Business rules change, no contract change Since there is no change to the API, consumers should not be affected
- We are not talking about bug fix. We are talking about business rules that change, and you want to have consumers to use multiple versions. E.g.: New mandatory regulation, but companies have X months to comply.
- Add a new parameter, version Id. That new parameter is validated for each request, and points to the desired source code. Site property prevents the module to be republish. Can be used, for e.g., when a critical error is found in the new version and you want to quickly revert to previous version.
- E.g.: Consumers may have to change the UI, to display new regulations. This works because we are talking about internal services with a governance model, version changes are informed to the teams using the service actions Impact analysis helps to find all consumers Add the input upfront, if your use case need to support multiple versions
- This becomes unmanaged over time. If you need to support too many older version, split the API.
- Consumers should be republished: may be broken or not, depending on the change. E.g.: Mandatory inputs break the consumer during runtime. What should we do?
- Keep your house clean: clean up old versions once no longer consumed
- But it forces producer/consumer to share common module, outside contract definition. Common modules tend to grow and become a bag of tricks, that when changed, force the entirue factory to be republished.
- Big boys talk
- This is, in my opinion, the biggest challenge: consumer runs in a different transaction than the producer.
- We all have planned for a nice vacation period, and needed to book a flight, a hotel and rent a car.
- Other scenario: I cannot cannot take my flight, but I want to maximize my lost. So I offer my ticket to a friend Step 1: Update traveler information. Step 2: A new online ticket must be re-issue
- The more services you have, the more difficult it is to manage the rollback, and keep track of what changed.
- Balance the granularity of your services VERSUS the need for isolated services.
- 20:00
- They called in business analysts and IT for a brainstorm session
- “Let’s make an awesome application, with responsive design” “Store Manager inputs the postal code and it directly prints the letters, ready to stamp!” “Awesome!”
- “Add one page to existing backoffice…” “Store manager inserts the postal code… that returns a list of local addresses - he can print the list and do the rest manually.”
- IS stands for Integration Service - technical wrapper to consume and normalize an external service.
- What? No Core Services? Not all designs have a core service. This is a clear example of a non-business functionality.
- If you don’t, you will be in denial for the rest of the presentation, my apologies upfront.
- To simplify the exercise, let’s assume we have only two parallel universes. The first one ignored climate-changes… while the second one was overzealous and eradicated ice all together.
- In both cases, this architecture translates into 2 Lifetime Applications. If you have different teams working, one on the Postal Services, other on the Store Manager, you should create a 3rd LT app, to expose the OAPI o team Store Manager. This is relevant for us to understand the independent release cycles.
- Both universes produced the same page. It’s time for user-testing.
- Add Country Code, as optional parameter.
- Publish only the Postal Services → Reinforce the strong vs weak REST service expects a mandatory input parameter → this could be prevented by managing different API versions
- In both cases, there is a warning consumers should be republished
- What about the release cycle? In both cases, Lifetime prevents you to deploy further this version and break the consumers. Why, because both are breaking changes. And although you are using Service Actions (weak dependency), the platform still you to deploy a broken contract. This is one advantage over REST API, where only at runtime the consumer will find out it’s broken.
- Go and update the code to show Portugal and not PT. Do not publish the UI
- In both universes, Lifetime allows you to move just the service application to the next environment, since there is nothing broken. The big difference is that the platform republish the consumers, for Server Actions, to ensure they have the latest version running.
- 30:00
- The final decision depends on your use case. This is an awareness session, let me give you some guidelines.
- 1st guideline: Balance your options. Keep in mind each service action is an internal REST call.
- Release Cycle The bigger the factory, the bigger the monolith, the slower code reaches production. Service Communication
- DB Transactions Development effort
- More than a single service, you want to control an entire business domain.
- 35:00
- Tell you account manager I sent you… not sure you will get a discount, but I may get a bonus!
- Take into consideration authentication and userId, ...
- I do hope you leave this session with more questions than answers… that will take you on a journey to look for new design patterns. Explore service oriented architecture… define your service APIs when applicable… break the monolith if you have one!
- Be careful how you use them, but please use them! “The difference between poison and remedy is the dosage” - Paracelsus Look into your architecture and create ONE service actions and see where that will take you. As always, OutSystems will be here to provide guidance in your journey