An "Integration" in the Rudder platform encompasses the client-side (Software Development Kit) enhancements as well as server-side (transformer) additions required in order to support a new "Destination" (analytics/digital marketing/CRM/backoffice platform or enterprise system).
The Rudder SDKs (web/mobile/server) helps developers capture business events within their enterprise systems and route the same to the Rudder BackEnd (server). The messages sent from the SDK client to the Rudder Server or BE follows a canonical model and is independent of the programming language or the source platform. The central engine of the Rudder BE is message-agnostic and performs resilient but optimised routing functions. The transformers are responsible for the final mapping from canonical message to destination-specific semantics.
Given the above high-level distribution of responsibilities among the various elements in the Rudder data pipeline, it might first appear that incorporation of a new Integration should involve only the development of a transformer since the canonical payload that would undergo the transformation would already be part of the existing SDK. However such is not the case due to the following reasons:
Most of the Destination platforms provide their own SDKs. While the Rudder BE relies on the Destination to offer some means of server-to-server communication, such communication support might not always be there and/or might not provide 100% coverage of the functionalities offered by the platform SDK. In such cases, the Rudder SDK has to rely on the Platform SDK to support the messages not addressed as part of the platform's server-side APIs
Certain platforms (especially those focused on attribution) rely on establishing a cross-device identifier for delivering actionable insight. Such an identifier is typically generated by proprietary systems within the platform that leverage cross-references gleaned from various other sources. In order to integrate with such platforms, Rudder depends on leveraging the platform SDK for establishing the identifier
In certain cases, the platform SDK captures events over and above its advertised APIs and in such cases, the Rudder SDK has no option but to include the platform SDK
We shall delve into the details of enhancing SDKs as well as developing transformers in the following sections
Rudder SDKs have two components
Core SDK - which provides the APIs that application developers need to use in order to route business events via the Rudder platform. Apart from routing events to the Rudder BE, the core SDK also implements a Factory pattern wherein the concrete implementations are the wrappers for the supported platform SDKs
Integration sub-component - which is actually a combination of the wrapper implementation and the actual platform SDK which the wrapper adapts to Rudder framework
Inclusion of a platform at development time can be controlled by including/excluding the corresponding integration sub-component in the Build. The core SDK prepares an inventory of the supported integration modules and includes only those in the Factory calls. Using this approach, the application size can be restricted to include only required components
Even after an integration component has been included in Build, its usage at runtime can still be controlled through appropriate server-side configurations which the client SDK downloads and uses. Using this approach developers can turn on or off - a direct flow of events to the destination
Please refer to https://app.gitbook.com/@rudderlabs/s/rudderlabs-1/~/drafts/-Lrrs1q5wf5yP6Md8Hzi/primary/ for details regarding developing Transformer programs