General architecture general-architecture

The typical Adobe Campaign solution deployment consists of the following components:

Adobe Campaign is based on a service-oriented architecture (SOA) and comprises several functional modules. These modules can be deployed on one or more computers, in single or multiple instances, depending on constraints in terms of scalability, availability and service isolation. The scope of deployment configurations is therefore very broad, and spans a single, central computer through to configurations including multiple dedicated servers over multiple sites.

Presentation layer presentation-layer

The application can be accessed in different ways, depending on the users’ needs: Rich client, Thin client or API integration.

Logical application layer logical-application-layer

Adobe Campaign is a single platform with different applications that combine to create an open and scalable architecture. The Adobe Campaign platform is written on a flexible application layer and is easily configurable to meet a company’s business needs. This accommodates the growing needs of the enterprise from a functional perspective as well as from a technical perspective. The distributed architecture ensures linear system scalability scaling from thousands of messages to millions of messages.

Adobe Campaign relies on a set of server-side processes that work together.

The main processes are:

Application server (nlserver web)

This process exposes the full range of Adobe Campaign functionality via Web Services APIs (SOAP - HTTP + XML). Furthermore, it can dynamically generate the Web pages used for HTML-based access (reports, Web forms, etc). To achieve this, this process includes an Apache Tomcat JSP server. This is the process to which the console connects.

Workflow engine (nlserver wfserver)

It executes the workflow processes defined in the application.

It also handles periodically executed technical workflows, including:

Delivery Server (nlserver mta)

Adobe Campaign has native email broadcast functionality. This process functions as an SMTP mail transfer agent (MTA). It performs “one-to-one” personalization of messages and handles their physical delivery. It functions using delivery jobs and handles automatic retries. In addition, when tracking is enabled, it automatically replaces the URLs so that they point to the redirection server.

This process can handle the customization and automatic sending to a third-party router for SMS, fax and direct mail.

Redirection server (nlserver webmdl)

For email, Adobe Campaign automatically handles open and click tracking (transactional tracking at the Web site level is a further possibility). To achieve this, the URLs incorporated in the email messages are rewritten in order to point to this module, which registers the passing of the internet user before redirecting them to the required URL.

To guarantee highest availability, this process is fully independent from the database: the other server processes communicate with it using SOAP calls (HTTP, HTTP(S) and XML) only. Technically, this functionality is implemented in an extension module of a HTTP server (ISAPI extension in IIS, or a DSO Apache module, etc.) and is available in Windows only.

Other more technical processes are also available:

Managing bounce emails (nlserver inMail)

This process enables you to automatically pick up email from mailboxes configured to receive bounced messages that are returned in case of delivery failure. These messages then undergo rule-based processing to determine the reasons for non-delivery (unknown recipient, quota exceeded, etc.) and to update the delivery status in the database.

All these operations are fully automatic and preconfigured.

SMS delivery status (nlserver sms)

This process polls the SMS router to collect progress status and update the database.

Writing log messages (nlserver syslogd)

This technical process captures log messages and traces generated by the other processes and writes them to the hard disk. This makes ample information available for diagnosis in case of problems.

Writing tracking logs (nlserver trackinglogd)

This process saves to disk the tracking logs generated by the redirecting process.

Writing inbound events (nlserver interactiond)

This process ensures the recording to the disk of inbound events, within the framework of Interaction.

Supervising modules (nlserver watchdog)

This technical process acts as a primary process which spawns the others. It also monitors them and relaunches them automatically in case of incidents, thus maintaining maximum system uptime.

Statistics server (nlserver stat)

This process maintains statistics on the number of connections, the messages sent for each mail server which messages are sent to, as well as their limitations (highest number of simultaneous connections, messages per hour/ and or connection). It also lets you federate several instances or machines if they share the same public IP addresses.

Persistence layer persistence-layer

The database is used as a persistence layer and contains almost all the information managed by Adobe Campaign. This includes both functional data (profiles, subscriptions, content, etc.), technical data (delivery jobs and logs, tracking logs, etc.) and work data (purchases, leads).

The reliability of the database is of utmost importance because the majority of Adobe Campaign components require access to the database in order to perform their tasks (with the notable exception of the redirection module).

The platform comes predefined with a marketing centered data mart or can easily sit atop an existing data mart and schema using any of the major Relational Database Management Systems (RDBMS). All data within the data mart is accessed by the Adobe Campaign platform via SQL calls from Adobe Campaign to the database. Adobe Campaign also provides a full complement of Extract Transform and Load (ETL) tools to perform data import and export of data into and out of the system.