Testing the journey

Before being able to test your journey, you must resolve all errors if any. See this section.

You have the possibility to test your journey before its publication, using test profiles. This allows you to analyze how individuals flow in the journey and troubleshoot before publication.

Only test profiles can enter a journey in test mode. You can either create a new test profile or turn an existing profile into a test profile. Refer to this section.

To use the test mode, follow these steps:

1. Before testing your journey, verify that it is valid and that there is no error. You won’t be able to launch a test of a journey with errors. See this section. A warning symbol is displayed when there are errors.

2. To activate the test mode, click on the Test toggle, located in the top right corner.

   

3. Use the Wait time parameter, in the bottom left corner, to define the time that each wait activity and event timeout will last in test mode. The default time is 10 seconds for waits and event timeouts. This will ensure that you get the test results quickly. This parameter only appears if you have dropped one or more wait activities in your journey.

   

   NOTE

   When a reaction event with a timeout is used in a journey, the wait time default and minimum value is 40 seconds. See this section.

4. Click Trigger an event to configure and send events to the journey.

   

5. Configure the different fields expected. In the Profile Identifier field, enter the value of the field used to identify the test profile. It can be the email address, for example. Make sure to send events related to test profiles. See Firing your events.

   

6. After the events are received, click the Show log button to view the test result and verify them. See Viewing the logs.

   

7. If there is any error, deactivate the test mode, modify your journey and test it again. When the test is conclusive, you can publish your journey. See this page.

Important notes

• An interface is provided to fire events to the tested journey but events can also be sent by third-party systems such as Postman.
• Only individuals flagged as “test profiles” in the Real-time Customer Profile Service will be allowed to enter the tested journey. Refer to this section.
• The test mode is only available in draft journeys that use a namespace. Test mode needs to check if a person entering the journey is a test profile or not and thus must be able to reach the Adobe Experience Platform.
• The maximum number of test profiles than can enter a journey during a test session is 100.
• When you disable the test mode, it empties the journeys from all people who entered it in the past or who are currently in it. It also clears the reporting.
• You can enable/disable the test mode as many times as needed.
• You cannot modify your journey when the test mode is activated. When in test mode, you can directly publish the journey, no need to deactivate the test mode before.
• When reaching a split, the top branch is always chosen. You can reorganize the position of the split branches if you want the test to choose a different path.
• To optimize performance and prevent obsolete resource usage, all journeys in test mode that have not been triggered for a week will switch back to the Draft status.

Turning a profile into a test profile

You can turn an existing profile into a test profile. In Adobe Experience Platform, you can update profiles attributes via API calls, but it cannot be performed via the interface.

The easiest way to do this is by using an Update profile action activity and change the test profile boolean field from false to true. See this section.

Creating a test profile

If you want to create a new test profile, the procedure is the same as when you create a profile in the Adobe Experience Platform. It is performed through API calls. See this page

You must use a Profile schema that contains the “profile test details” mixin. The testProfile flag is part of this mixin.

When creating a profile, make sure you pass the value: testProfile = true.

Note that you can also update an existing profile to change its testProfile flag to “true”.

Here is an example of an API call to create a test profile:

curl -X POST \
'https://dcs.adobedc.net/collection/xxxxxxxxxxxxxx' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-H 'Postman-Token: xxxxx' \
-H 'cache-control: no-cache' \
-H 'x-api-key: xxxxx' \
-H 'x-gw-ims-org-id: xxxxx' \
-d '{
"header": {
"msgType": "xdmEntityCreate",
"msgId": "xxxxx",
"msgVersion": "xxxxx",
"xactionid":"xxxxx",
"datasetId": "xxxxx",
"imsOrgId": "xxxxx",
"source": {
"name": "Postman"
},
"schemaRef": {
"id": "https://example.adobe.com/mobile/schemas/xxxxx",
"contentType": "application/vnd.adobe.xed-full+json;version=1"
}
},
"body": {
"xdmMeta": {
"schemaRef": {
"contentType": "application/vnd.adobe.xed-full+json;version=1"
}
},
"xdmEntity": {
"_id": "xxxxx",
"_mobile":{
"ECID": "xxxxx"
},
"testProfile":true
}
}
}'

Firing your events

The Trigger an event button allows you to configure an event that will make a person enter the journey.

As a prerequisite, you must know which profiles are flagged as test profiles in the Adobe Experience Platform. Indeed, the test mode only allows these profiles in the journey and the event must contain an ID. The expected ID depends on the event configuration. It can be an ECID or an email address for example. The value of this key needs to be added in the Profile Identifier field.

If your journey contains several events, use the drop-down list to select an event. Then, for each event, configure the fields passed and the execution of the event sending. The interface helps you pass the right information in the event payload and make sure the information type is correct. The test mode saves the last parameters used in a test session for later use.

The interface allows you to pass simple event parameters. If you want to pass collections or other advanced objects in the event, you can click on Code View to see the entire code of the payload and modify it. For example, you can copy and paste event information prepared by a technical user.

A technical user can also use this interface to compose event payloads and trigger events without having to use a third-party tool.

When clicking the Send button, the test begins. The progression of the individual in the journey is represented by a visual flow. The path progressively turns green as the individual moves across the journey. If an error occurs, a warning symbol is displayed on the corresponding step. You can place the cursor on it to display more information about the error and access full details (when available).

When you select a different test profile in the event configuration screen and run the test again, the visual flow is cleared and shows the path of the new individual.

When opening a journey in test, the displayed path corresponds to the last test executed.

The visual flow works whether the event is triggered via the interface or externally (using Postman, for example).

Test mode for rule-based journeys

The test mode is also available for journeys that use a rule-based event. For more information on rule-based events, refer to this page.

When triggering an event, the Event configuration screen allows you to define the event parameters to pass in the test. You can view the event ID condition by clicking the tooltip icon in the top right corner. A tooltip is also available next to each field that is part of the rule evaluation.

For more information on how to use the test mode, refer to this page.

Viewing the logs

The Show log button allows you to view the test results. This page displays the journey’s current information in JSON format. A button allows you to copy entire nodes. You need to manually refresh the page to update the journey’s test results.

The number of individuals (technically they are called instances) currently inside the journey are displayed. Here is useful information that is displayed for each individual:

• Id: the individual’s internal ID in the journey. This can be used for debugging purposes.
• currentstep: the step where the individual is at in the journey. We recommend adding labels to your activities to identify them more easily.
• currentstep > phase: the status of the individual’s journey (running, finished, error or timed out). See below for more information.
• currentstep > extraInfo: description of the error and other contextual information.
• currentstep > fetchErrors: information on fetch data errors that occurred during this step.
• externalKeys: the value for the key formula defined in the event.
• enrichedData: the data that the journey has retrieved if the journey uses data sources.
• transitionHistory: the list of steps that the individual followed. For events, the payload is displayed.
• actionExecutionErrors : information on the errors that occurred.

Here are the different statuses of an individual’s journey:

• Running: the individual is currently in the journey.
• Finished: the individual is at the end of the journey.
• Error: the individual is stopped in the journey because of an error.
• Timed out: the individual is stopped in the journey because of a step which took too much time.

When an event is triggered using the test mode, a dataset is automatically generated with the name of the source.

When an event is triggered using the test mode, a dataset is automatically generated with the name of the source.

The test mode automatically creates an Experience Event and sends it to Adobe Experience Platform. The name of the source for this experience Event is “Journey Orchestration Test Events”.