I'm having trouble understanding the difference between these two concepts. Normally I use the IS module to consume an API, I read some articles on this topic and saw many examples where the module that consumed the API was the driver and then the IS module consumed the driver.
but I don't understand the objective of using a driver and then using an IS, what is the advantage? What is the problem with using only one IS module?tks
Hi @João Vilelas
I think I can explain your question with an example.
An _IS module handles the connection to different payment APIs (e.g., Stripe, PayPal, Square).
Each _IS module will manage authentication, data formatting, and error handling specific to the payment provider.
A _Drv module exposes a common API for payments (e.g., ProcessPayment, RefundPayment) and decides which _IS module to call based on the selected payment gateway.
This allows the app to treat all payment systems the same way, even though the underlying APIs are different.
Hello AndreIf it's not too much to ask, can you make an example, but via OML please, it's still not very clear to me.
@André Costa ,
It is the other way around, each _drv is specific for a consumed api. The _is acts as a wrapper to make these details transparent / irrelevant for the consuming OutSystems application.
You can find implementation of these pattern in Integration Builder generated modules. Please have a look at Structure of generated integrations. Notice that the library module (DRV) interacts directly with the external provider, while the service module (IS) acts as a wrapper over it, allowing top layers to interact with the service module. See the section 'Use the integration in Service Studio @ Use Integration Builder
Hello Joao,
The additional layer while implementing the integrations is to bring in abstraction. The driver module contains logic to deal directly with specific external system and the IS layer sits in between to provide a cushion as well as additional logic to deal with various drivers. This helps to ensure that changes happening on the external system don't break the consumers.
For better use case you can look at sample Transparency Service section in below documentation.
https://success.outsystems.com/documentation/best_practices/architecture/designing_the_architecture_of_your_outsystems_applications/integration_patterns_for_core_services_abstraction/
There is also another public article which might provide you more insights.
https://itnext.io/best-practice-integration-services-in-outsystems-6469d1b85ffb
Hope it helps!
Junaid