Adobe Campaign Classic Architect Master cheat sheet

Adobe Campaign Classic uses a three-tier logical architecture: presentation (rich client/Web UI), application (campaign, workflow, and web modules on the Adobe Campaign server), and data (the RDBMS).

The marketing (application) server and the database server must reside in the same data center with low latency; the client can be remote.

The mta (Message Transfer Agent) process handles outbound delivery and can be deployed on a separate server behind a reverse proxy for IP reputation and throughput isolation.

The inMail / interaction module runs on the application server and is required for inbound email processing and real-time inbound channel routing.

The web module (nlserver web) hosts landing pages, web applications, and public-facing URLs; it must be exposed through a front-end reverse proxy or load balancer.

Redundancy is achieved by deploying multiple application servers behind a load balancer, all pointing to a shared RDBMS and shared file storage.

The tracking (redirect) server must be reachable from recipients' browsers and is typically separated from the marketing server for security and performance.

Message Center (real-time transactional messaging) requires a dedicated execution instance and its own MTA; the transactional message template is linked to a routing.

Snowflake / hybrid architectures are not native to Classic; Classic is RDBMS-centric (PostgreSQL, Oracle, SQL Server, or DB2 depending on version).

Core out-of-the-box schemas: nmsRecipient (recipient), nmsGroup (group), nmsDelivery (delivery), nmsBroadLog (broad log), nmsTrackingLog (tracking log), nmsSubscription (subscription), nmsAddress (address).

Schema extension is done via with the extends attribute or via the Extend tab in the schema editor; new fields are added as under .

The @autopk attribute on a schema key enables automatic numeric primary key; otherwise the primary key is a string (typically 32-char) generated by the platform.

The @sqltable attribute overrides the physical table name; @mappingSchema controls the schema used for the mapping (e.g., nms:recipient).

Link cardinality is declared with the element; the @revLink attribute defines the reverse link on the target schema.

The @integrity attribute on a link controls referential integrity (true/false); @revIntegrity controls the reverse side.

Indexes are declared with inside the schema; a unique index uses @unique="true".

The data model is deployed to the database via the Database Structure wizard (Tools > Advanced > Update database structure), which generates the SQL DDL.

The nms:recipient schema's @folder/@folderId fields control the recipient folder; @domain controls domain-based deduplication when @deduplication is enabled.

Workflow activities are typed: targeting (Query, Union, Intersection, Exclusion, Change data source), delivery (Delivery, Continuous delivery), flow control (Wait, Fork, AND-join, Test), and action (Update data, Enrichment, JavaScript code, External signal).

The Query activity is the primary targeting tool; its targeting dimension is set by the schema selected in the activity properties.

The Enrichment activity adds data from a linked or unrelated table via a join or a sub-query; the added data is available to downstream activities.

The Fork activity creates parallel branches; the AND-join activity waits for all incoming transitions before continuing.

The Scheduler activity triggers a workflow on a recurring schedule; the External signal activity resumes a workflow when an external process calls the signal.

The Update data activity modifies the targeting dimension; the Delivery activity sends to the current targeting dimension.

Workflow execution is asynchronous; the workflow engine (wfserver) processes the workflow jobs and the mta handles delivery sending.

The workflow log (Administration > Production > Technical workflows or the workflow's audit) records activity execution and errors; the log level is configurable per workflow.

Technical workflows (e.g., cleanup, tracking, billing) run on the application server and must not be deleted; they are identified by the @internal="true" attribute.

The SOAP API (nl.wsdl) exposes the data model via the xtk:session, xtk:queryDef, xtk:persist, and xtk:workflow schemas; the WSDL is at /nl/jsp/xtk.wsdl.

The REST API (Campaign Standard-style) is not native to Classic; Classic integrations typically use SOAP, the JavaScript API (NLWS), or the JSSP web application framework.

The JavaScript API uses NLWS (e.g., NLWS.xtkSession.logon, NLWS.xtkQueryDef.createQuery) and is available in the web module and in workflow JavaScript activities.

The xtk:queryDef schema supports select, where, orderBy, and lineCount; the @operation attribute is "select", "get", or "getIfExists".

The xtk:persist schema supports insert, update, and delete; the @operation attribute controls the action.

The JSSP (JavaScript Server Pages) framework hosts web applications under /nl/jsp/; the application is declared in the web module and uses the <%@ page %> directive.

The External signal activity can be triggered via the SOAP API by calling the xtk:workflow PostEvent method with the workflow ID and signal name.

The Data loading (file) activity reads CSV/XML files; the Data extraction (file) activity writes files; the file format is defined in the activity's properties.

The Web download activity retrieves a file over HTTP; the File transfer activity handles SFTP/FTP transfers.

The MTA throughput is governed by the number of mta processes, the number of threads per process, and the delivery connection settings; the default is 1 process with multiple threads.

The delivery throughput formula: messages per hour = (threads per mta) x (messages per second per thread) x 3600; the per-thread rate depends on the receiving MTA and network.

The tracking log table (nmsTrackingLog) grows fastest; the cleanup technical workflow purges it according to the retention period set in the deployment wizard.

The broad log table (nmsBroadLog) is the second-largest table; purge retention is set per delivery type (email, SMS, push) in the deployment wizard.

Database indexes on the targeting dimension and on the broad log's delivery ID are critical for query performance; missing indexes cause full table scans.

The workflow engine processes one operation per workflow at a time; long-running workflows should be split into multiple workflows to parallelize.

The application server's Java heap (JVM) and the database's shared buffers are the primary memory tuning parameters; the JVM heap is set in the nlserver startup configuration.

The number of concurrent users is limited by the application server's connection pool and the database's max connections; the pool size is set in the server configuration.

The delivery's "wave" scheduling (delivery waves) distributes sending over time to avoid overwhelming the MTA and the receiving MTAs.

Operators (nmsOperator) are the users; they authenticate with a login and password or with an external directory (LDAP).

Security zones (nmsSecurityZone) restrict operator access to specific folders and to specific IP addresses; an operator can belong to multiple zones.

Named rights (nmsNamedRight) grant granular permissions such as "admin", "workflow", "delivery", and "schema"; rights are assigned to operators or to groups (nmsGroup).

Folder permissions (nmsFolder) control which folders an operator can see and edit; the folder's security is defined by the operator's security zone.

The "admin" named right grants full access and bypasses folder restrictions; it should be limited to a small set of operators.

The password policy (minimum length, complexity, expiration) is configured in the deployment wizard's security settings.

The audit log (xtkAudit) records operator actions; the audit trail is enabled per schema in the schema's @logAuditTrail attribute.

The delivery's "from" address and the domain's SPF/DKIM/DMARC records are configured in the delivery template and in the DNS; the MTA signs with DKIM if configured.

The tracking server must use HTTPS; the SSL certificate is configured in the web module's server configuration.

The deployment wizard (Tools > Advanced > Deployment wizard) configures the instance: database connection, MTA, web, tracking, and security settings.

Package export (Tools > Advanced > Export package) exports schemas, workflows, delivery templates, and other objects to an XML package; the package is imported in the target environment.

The package's @uninstall attribute controls whether the package is uninstalled when the target object is removed; the @buildOnly attribute controls whether the package is built only.

The schema's @namespace and @name identify the object; the package's element lists the schemas to export.

The data model is deployed to the database via the Database Structure wizard; the wizard generates the SQL DDL and applies it to the database.

The "Update database structure" wizard compares the schema definitions to the physical database and generates the ALTER TABLE statements.

Environment promotion follows the path: development > staging > production; each environment has its own database and its own nlserver instance.

The configuration file (config-.xml) holds the instance's settings; it is not part of the package export and must be managed separately.

The "Generate the JavaScript code" step in the deployment wizard compiles the schemas' JavaScript code; it must be run after schema changes.

The JavaScript API (NLWS) exposes the data model: NLWS.xtkSession.logon, NLWS.xtkQueryDef.createQuery, NLWS.xtkPersist.createPersist.

The query definition's element uses XPath-like expressions: @field = 'value', @field = 1, and the @filter attribute for named filters.

The JavaScript code activity in a workflow runs server-side JavaScript with access to the workflow's variables via the task object (e.g., task.vars).

The element in a schema defines a computed boolean field; the element defines a computed string field.

The element defines a list of values; the field's @enum attribute references the enumeration.

The element in a schema defines custom methods callable from JavaScript; the method's @name and @arguments attributes define the signature.

The element in a schema defines a custom event that can be triggered and handled by a JavaScript handler.

The web application's JavaScript can call the NLWS API; the application's login is managed by the web module's session handling.

The

element in a schema defines the edit form; the form's elements map to the schema's fields.

The nlserver monitor command (nlserver monitor -instance:) returns the instance's status as XML, including process status and queue sizes.

The log files are in the instance's log directory (e.g., /var/log/nlserver or the nlserver log folder); the mta, web, and wfserver processes each write their own log.

The delivery's audit (delivery > Audit) records the delivery's lifecycle events: creation, target computation, sending, and completion.

The workflow's audit (workflow > Audit) records activity execution; the log level is set in the workflow's properties.

The "Database structure" wizard reports schema/database mismatches; a mismatch causes runtime errors such as "column does not exist".

The tracking log's "tracking" technical workflow processes the redirect and open logs; a stalled workflow causes tracking data to be delayed.

The cleanup technical workflow purges the broad log, tracking log, and other tables; its retention periods are set in the deployment wizard.

The mta's queue can be inspected with nlserver monitor; a growing queue indicates a delivery bottleneck or an unreachable receiving MTA.

The "Replicate" and "Sync" technical workflows synchronize data between the marketing instance and the execution instance in a mid-sourcing architecture.