Free AD0-E330 Practice Test

This sequence represents a standard and robust pattern for a daily data import and update process in Adobe Campaign Classic.
1. Scheduler: Initiates the workflow on a recurring daily basis.
2. File transfer: Securely downloads the data file from the external Amazon S3 bucket to the Adobe Campaign server. This activity is designed for various protocols, including S3.
3. Data loading (file): Reads the downloaded file, parses its contents, and loads the data into a temporary worktable within the workflow.
4. Update data: Uses the records from the worktable (passed through the transition) to perform a mass insert or update operation on the final, existing Campaign table, reconciling records based on a specified key.

A. File collector is less appropriate than File transfer for accessing an S3 bucket; it's primarily for monitoring a local or SFTP directory.
C. Data extraction is incorrect. This activity exports data from the Campaign database to a file, which is the opposite of the required import operation.
D. This option contains two incorrect activities. File collector is not the best choice for S3, and Data extraction performs an export, not an import.

1. Adobe Experience League | Campaign Classic v7 Documentation

Workflow Activities

File transfer: This document specifies that the File transfer activity "lets you receive or send files... It can be used with various protocols

including Amazon S3

" confirming it as the correct choice for retrieving the file.

2. Adobe Experience League | Campaign Classic v7 Documentation

Workflow Activities

Data loading (file): This source describes the activity's function: "The Data loading (file) activity lets you directly access a data source in order to import it into the database." This validates its use for processing the downloaded file.

3. Adobe Experience League | Campaign Classic v7 Documentation

Use cases

Updating data with data from a file: This official use case guide outlines a workflow to "update the data in the database with the content of a file." The described process involves loading the file's content and then using an Update data activity to "link the data from the file to the data in the database and to update the chosen fields

" directly supporting the Data loading -> Update data sequence.

4. Adobe Experience League | Campaign Classic v7 Documentation

Workflow Activities

Data extraction (file): The documentation states

"The Data extraction (file) activity... lets you extract data and store it in a file." This confirms it is for exporting and thus incorrect for this import scenario.

Disabling an operator's account in Adobe Campaign Classic only revokes their login privileges. The operator's profile, which includes their email address and group memberships, remains active within the system's database. System alerts and notifications configured to be sent to specific operators or operator groups (e.g., 'Administrators') will continue to be sent to the email address on the disabled profile. The only definitive way to stop all platform-related communications and fully offboard the user is to permanently delete their operator profile from the instance.

A. Removing the email address from their profile is an incomplete solution that leaves an unnecessary and orphaned operator record in the system.
C. Updating access settings only modifies the operator's permissions within the platform; it does not control system-generated notifications sent to their email address.

1. Adobe Experience League, Campaign Classic v7 Documentation, "Creating an operator and setting permissions." This document details the operator configuration options, including the "Disable account" checkbox. It clarifies that this action is for suspending access, not for complete removal. The operator entity itself continues to exist. (See section on operator parameters).

2. Adobe Experience League, Campaign Classic v7 Documentation, "List of operators." This guide illustrates the process of managing operators, including the "Delete" action. Deleting an operator is the procedure for permanent removal from the system, which is necessary to sever all ties, including notification subscriptions.

3. Adobe Experience League, Campaign Classic v7 Documentation, "Alerts" (within Workflow general operation). This section explains how alerts can be configured to notify operators in case of errors. It states, "The alert can be sent to the workflow supervisor... or to one or more other operators." This confirms that notifications are tied to the existence of an operator record, not its enabled/disabled login status.

To meet the requirements, the workflow must be initiated on a recurring schedule and must prevent sending duplicate notifications. The Scheduler activity is the correct tool to trigger a workflow at a defined, repeating interval, such as every 15 minutes. After an initial targeting activity (e.g., a Query) selects all users who meet the event criteria, a Test activity is necessary. This Test activity acts as a filter, checking if a user has already been targeted in a previous run of this same workflow (e.g., by checking delivery logs) and excluding them from the current execution, thus fulfilling the "no duplicates" requirement.

A. A Test activity before targeting is illogical because there is no audience defined yet to be tested or filtered.
B. A Wait activity only pauses a single workflow execution for a set duration; it does not re-trigger the entire workflow on a recurring schedule.
C. This option is incorrect for two reasons: a Wait activity cannot create a recurring schedule, and a Test activity cannot function properly before a target audience is defined.

1. Adobe Experience League - Campaign Classic v7 Documentation, "Scheduler". In the "Properties" section, the documentation states, "The Scheduler activity is used to trigger the execution of a workflow at a planned date and time." It details the "Execution frequency" parameter, which allows for repeated execution at set intervals (e.g., every N minutes), directly addressing the "every 15 minutes" requirement.

2. Adobe Experience League - Campaign Classic v7 Documentation, "Test". The documentation explains, "The Test activity allows you to use one or more activation conditions for a transition." This confirms its role in splitting a target population based on a condition, which is the necessary logic to filter out recipients who have already received the notification. The activity must be placed after the target population is defined.

3. Adobe Experience League - Campaign Classic v7 Documentation, "Workflow activities". The general structure of targeting workflows shows that scheduling activities initiate the process, followed by targeting activities to build an audience, and then segmentation or filtering activities (like Test or Exclusion) to refine the audience before a delivery. This confirms the logical sequence of Scheduler -> Targeting -> Test.

Adobe Campaign Classic provides robust API capabilities for integration with external systems. The question specifies that the source CRM system relies on HTTP communication to push data. Adobe Campaign Classic exposes two primary types of HTTP-based APIs for this purpose:
1. SOAP APIs: This is the main set of web services in Campaign Classic, allowing for comprehensive operations on the data model, including creating and updating profiles (recipients) using methods like Write and WriteCollection.
2. REST APIs: Campaign Classic also offers REST APIs, particularly for profile and service management (profileAndServicesExt API), which allow external systems to create or update profiles via standard HTTP methods like POST and PATCH. Both SOAP and REST are built on the HTTP protocol, directly satisfying the customer's requirement.

B. External Account: An External Account is a configuration within Adobe Campaign to connect outbound to other systems (e.g., a database or SFTP server), typically for data extraction or loading via a workflow. It is not an inbound endpoint for receiving data pushes.
D. SFTP: SFTP (Secure File Transfer Protocol) is a file-based protocol that operates over SSH, not HTTP. While a valid integration method for Campaign Classic, it does not meet the specific requirement of using HTTP communication.

1. Adobe Experience League, Campaign Classic v7 Documentation, "Web services (SOAP)": This section details the use of SOAP protocol calls for data-oriented APIs. It states, "The data-oriented APIs let you interact with the objects in the data model of the Adobe Campaign database... The main data-oriented services are xtk:queryDef and xtk:session." The xtk:session service includes the Write method for creating/updating entities like profiles.

2. Adobe Experience League, Campaign Classic v7 Documentation, "Transactional messaging APIs > Event description": This document describes the REST API for pushing events, which involves identifying or creating a profile. It shows a sample REST call: POST /rest/head/event. This confirms the existence and usage of REST APIs for profile interaction.

3. Adobe Experience League, Campaign Classic v7 Documentation, "Managing profiles": This page explicitly details using the REST API to create, update, or retrieve profiles. It provides the endpoint structure, such as GET /profileAndServicesExt/profile/, and describes using POST to create a new profile, directly supporting the REST option.

4. Adobe Experience League, Campaign Classic v7 Documentation, "External accounts": This documentation describes the purpose of external accounts: "External accounts let you define the parameters for connecting to external systems: server, ID, password, etc." It lists types like External Database, FTP, SFTP, and AWS S3, confirming they are for Campaign-initiated connections, not for receiving API calls.

To retrieve data from multiple schemas and insert it into a temporary table within a workflow's JavaScript activity, a two-step process is required. First, Xtk.queryDef.create() is used to instantiate a query definition object. This object allows the developer to define the target schema, select columns (including those from linked schemas via joins), and specify filtering conditions. After executing the query, the developer iterates through the result set. For each record retrieved, the xtk.session.write() method is called to perform an INSERT or UPDATE operation, writing the data into the designated temporary table.

B. Xtk.workflow.execute() This function is used to programmatically start another workflow; it does not manipulate data within the current workflow's context.
C. Xtk.queryDef.Update() This is not a valid method for the queryDef object in the Adobe Campaign Classic JavaScript API. Data writing is handled by session methods.

1. Adobe Campaign Classic v7 Documentation, JSAPI Reference, queryDef class: This document details the create(queryDef) static method for creating a query definition instance. It is the standard starting point for building and executing queries in server-side JavaScript. The examples show its use for data selection. (See section: queryDef class description and create(queryDef) method).

2. Adobe Campaign Classic v7 Documentation, JSAPI Reference, xtk.session static class: This documentation outlines the write(entity) method. It explicitly states the method "Writes an entity in the database (INSERT or UPDATE)." This is the correct function for persisting the data retrieved by the queryDef into the temporary table. (See section: xtk.session class, write(entity) method).

3. Adobe Campaign Classic v7 Documentation, JSAPI Reference, xtk.workflow static class: This source describes the execute(workflowId) method, confirming its purpose is to execute a workflow identified by its ID, which is irrelevant to the data manipulation task described in the question. (See section: xtk.workflow class, execute(workflowId) method).

In Adobe Campaign v8, when working with Campaign Cloud (Snowflake), the staging mechanism is used to move data between the local (PostgreSQL) and cloud (Snowflake) databases.

• Initial Setup: You must first create and persist the base schema without staging to establish the underlying table structure.
• Activation: The autoStage="true" attribute is then added to the schema.
• Execution: Running the database update at this point triggers the creation of the technical staging table on the local Campaign database instance. This local table acts as a buffer for data ingestion before it is synchronized to the Cloud database.

Adobe Campaign v8 Documentation: Architecture - Snowflake - Staging mechanism. (Section: "Implementing a staging table").

Adobe Campaign v8 Documentation: Developer Guide - Schema Configuration. (Section: "Schema attributes: autoStage").

Adobe Experience League: Work with Campaign Cloud (FFDA) - Data Management. (Paragraph regarding local vs. cloud table synchronization).

Adobe Campaign v8 Technical Reference: Database Schema Updates and Synchronization for FFDA environments. (Standard procedure for schema modification).

A custom target mapping in Adobe Campaign Classic is fundamentally used to define a delivery destination other than the default recipient table (nms:recipient). Its primary use case is to enable sending deliveries to profiles whose data, including their delivery address (e.g., email), is stored in a separate, custom table or schema. This is necessary for scenarios such as targeting event attendees, subscribers to a specific service, or any other audience segment managed independently from the main recipient database. The mapping links the delivery process to this custom table, specifying which fields contain the address, recipient ID, and other necessary data.

A. Include seed addresses in the delivery: Seed addresses are a standard delivery feature used for testing and monitoring, and they can be added to any delivery without requiring a custom target mapping.
B. Retarget on the basis of segmentation: Retargeting is a marketing strategy executed via workflows and queries. While it can be applied to audiences in custom tables, the act of retargeting itself does not necessitate creating a custom mapping; the mapping is a prerequisite for targeting the custom table in the first place.

1. Adobe Campaign Classic v7 Documentation, "About target mappings": This document explicitly states, "By default, deliveries are aimed at recipients. But you can also deliver to other types of targets... To do this, you need to create a new target mapping." This confirms that the purpose is to target data stored outside the default recipient table. The section "Creating a new target mapping" details the process, which starts with creating a new data schema (i.e., an individual table).

2. Adobe Campaign Classic v7 Documentation, "Use case: delivering to subscribers": This guide provides a practical example that directly supports the correct answer. It walks through the entire process of creating a custom schema for subscribers (nms:subscribers), populating it, and then creating a new target mapping to enable sending deliveries to this distinct list of individuals stored in their own table. This exemplifies storing addresses in an individual table and using a custom mapping to target them.

The operationMgt (Campaign process) workflow is the central scheduler in Adobe Campaign Classic. It is responsible for triggering various background tasks, including initiating other workflows that are queued to run. When multiple workflows are stuck in a "start as soon as possible" status and the workflow heat map shows no activity, it strongly indicates that the core scheduling process itself has halted. Therefore, the most logical and critical next step is to verify that the operationMgt technical workflow is running correctly. If it has stopped or failed, no new workflows will be started by the wfserver process.

A. Stop and restart all the workflows that are stuck in a 'start as soon as possible' status This action treats the symptom, not the cause. If the underlying scheduler (operationMgt) is not running, restarting the workflows will simply place them back into the same queue without resolution.
B. Conditional stop and restart all the workflows that are stuck in a 'start as soon as possible' status Similar to option A, this is a reactive measure that fails to diagnose the root cause. The problem is not with the individual workflows but with the system's ability to start them.

1. Adobe Campaign Classic v7 Documentation - Technical Workflows: The operationMgt (Campaign process) workflow is described as the "scheduler" which is responsible for launching most of the jobs on the instance. "It is triggered at instance startup and then runs every 10 seconds. It is in charge of the following tasks: ... Triggering workflows that are scheduled to be executed." This confirms its role as the primary scheduler. (See section: Technical Workflows > Campaign process (operationMgt)).

2. Adobe Experience League - Campaign Classic - Monitoring Guide: In the section on instance supervision, checking the status of technical workflows is a primary step. The guide states, "The main processes (workflows) must be running on the instance(s)." It lists operationMgt as a critical workflow whose failure would impact the entire platform's automated operations, including starting other workflows. (See section: Production monitoring > Instance supervision > Checking the status of technical workflows).

A JSSP (JavaScript Server-Side Pages) webpage is the appropriate method for this use case. JSSPs are dynamic pages processed on the Adobe Campaign server. A developer can write server-side JavaScript within a JSSP to query the Campaign database using APIs like xtk.queryDef. The JSSP can then format the retrieved data as JSON, XML, or HTML and serve it over HTTP. The client's website can make an AJAX call to the JSSP's URL to fetch this data in real-time and display it to the end-user. This effectively creates a custom API endpoint for the external website to consume.

A. External accounts: These are configured within Campaign to connect to external systems (e.g., SFTP servers, external databases, cloud storage), primarily for data import/export tasks, not for external systems to query Campaign.
B. Data Schema methods: While schema methods (SOAP calls) are the underlying functions for data manipulation, they are not directly exposed to the web. JSSP is the presentation layer technology used to create a web-accessible endpoint that would, in turn, call these methods.

1. Adobe Experience League Documentation - JavaScript in web applications (JSSP): "JSSP (JavaScript Server-Side Pages) are used to create dynamic pages. These pages contain JavaScript code that is interpreted by the server... JSSP pages can be used to: display content from the database..." This source directly states that JSSPs are used to display content from the database on a page.

Source: Adobe Campaign Classic v7 Documentation

Developing > Web applications > JavaScript in web applications (JSSP).

2. Adobe Experience League Documentation - About web applications: "Web applications let you create and post dynamic and interactive web pages that can be accessed via a browser... A web application is made up of one or more pages (JSSP)." This establishes that JSSP is the core technology for creating web-accessible pages in Campaign.

Source: Adobe Campaign Classic v7 Documentation

Developing > Web applications > About web applications.

3. Adobe Experience League Documentation - QueryDef: The explanation mentions using xtk.queryDef within a JSSP. This documentation details how to build and execute queries against the Campaign database

which is the server-side action performed within the JSSP.

Source: Adobe Campaign Classic v7 Documentation

Developing > JavaScript scripts and templates > QueryDef.

The Target Mapping configuration within a delivery is the precise location where a developer links data from the incoming workflow transition (the target data) to the delivery's context. This interface provides an explicit option, typically a checkbox labeled "Keep this data in the broad log" or similar, for each mapped attribute. Selecting this option instructs Adobe Campaign to automatically capture and store the value of that attribute from the target data into the broad log schema (nms:broadLogRcp) for each recipient at the moment the delivery is sent.

A. Delivery Activity: This is too general. Target Mapping is a specific configuration within the Delivery Activity, not the activity itself.
B. Target Data: This refers to the actual data set being used for targeting and personalization, not a configuration interface for logging.
D. Extend Schema: While extending the broad log schema (nms:broadLogRcp) is a necessary prerequisite to create the field for the new attribute, it does not configure the capture of data into that field during a delivery.

1. Adobe Experience League - Campaign Classic v7 Documentation, "Target mapping": "The Target mapping link lets you link the data from a temporary workflow table to the data in the delivery logs. [...] You can store additional data in the logs. To do this, select the Keep this data in the broad log option." (This section explicitly details the function of mapping workflow data to the broad log).

2. Adobe Experience League - Campaign Classic v7 Documentation, "Enriching delivery content": In the section describing how to add personalization fields from a workflow, the documentation states: "In the Target mapping tab of the delivery properties, you can specify where the additional data is stored. By default, it is not stored. If you want to keep it, for example to use it in other messages, select the Keep this data in the broad log option." (This provides a use-case and confirms the configuration location).