Migration of Campaign technical operators to Adobe Developer Console

Starting Campaign v8.5, the authentication process to Campaign v8 is being improved. Technical operators must use Adobe Identity Management System (IMS) to connect to Campaign. A technical operator is a Campaign user profile which has been explicitly created for API integration. This article details the steps required to migrate a technical operator to technical account on Adobe Developer console.

What changed?

Campaign regular users already connect to the Adobe Campaign console using their Adobe ID, through Adobe Identity Management System (IMS). As part of the effort to reinforce security and authentication process, Adobe Campaign Client application now calls Campaign APIs directly using the IMS technical account token.

Learn more about the new server to server authentication process in Adobe Developer Console documentation.

This change is applicable starting Campaign v8.5, and will be mandatory starting Campaign v8.6.

Are you impacted?

If you are using Campaign APIs, you need to migrate your technical operator(s) to Adobe Developer Console as detailed below.

How to migrate?

Each technical operator should have at least one technical account.

Key steps are:

  1. First create the technical account corresponding to technical operator. For example, suppose the newly created technical account (TA1) for technical operator (TO1).
  2. Execute the steps detailed below on the technical account TA1
    Step 4 is optional and only required if the technical operator has specific folder permissions.
  3. Migrate all the Campaign API integration implementation to the newly created technical account TA1.
  4. Once all the customer facing API/Integration start fully functional on TA1, replace the technical operator TO1 with technical account TA1.

Prerequisites

Before starting the migration process, you must reach out to your Adobe Transition Manager so that Adobe technical teams can migrate your existing Operator groups and Named rights to Adobe Identity Management System (IMS).

Step 1 - Create/update your Campaign project in Adobe Developer Console

Integrations are created as part of a Project within Adobe Developer Console. Learn more about Projects in Adobe Developer Console documentation.

You can use any project previously created by you or you can create a new project. The steps to create a project are detailed in the Adobe Developer Console documentation.

For this migration, you must add below APIs in your project: I/O Management API and Adobe Campaign.

Step 2 - Add an API to your project using Server to Server authentication

Once your project is created in the Adobe Developer Console, add an API that uses Server-to-Server authentication. Learn how to set up the OAuth Server-to-Server credential in Adobe Developer Console documentation.

When the API has been successfully connected, you can access the newly generated credentials including Client ID and Client Secret, as well as generate an access token.

Step 3 - Add the product profile to the project

You can now add your Campaign product profile to the project, as detailed below:

  1. Open the Adobe Campaign API.

  2. Click the Edit product profiles button

  3. Assign all the relevant Product Profiles to the API, for example ‘messagecenter’, and save your changes.

  4. Browse to the Credential details tab of your project, and copy the Technical Account Email value.

Step 4 - Update the technical operator in the Client Console

This step is only required if specific folder permissions or named rights have been defined for this operator (not via the operator’s group).

You now need to update the newly created technical operator in Adobe Campaign Client Console. You must apply the existing technical operator folder permissions to the new technical operator.
To update this operator, follow these steps:

  1. From Campaign Client Console explorer, browse to the Administration > Access Management > Operators.
  2. Access the existing technical operator used for APIs.
  3. Browse to the folder permissions, and check rights.
  4. Apply the same permissions to the newly created technical operator. This operator’s email is the Technical Account Email value copied earlier.
  5. Save your changes.
CAUTION

The new technical operator must have made at least one API call to be added to Campaign Client Console.

Step 5 -Validate your configuration

To try out the connection, follow the steps detailed in the Adobe Developer Console credentials guide for generating an access token and copy the Sample cURL command provided.

Step 6 - Update the third-party API integrations

You must update the API integrations with your third-party systems.

For further more details about API integration steps, including a sample code for smooth integration, refer to Adobe Developer Console authentication documentation.

Step 7 - Remove the old technical operator

After the migration of all API/custom code integration with Technical account user. You can delete the old technical operator from Campaign client console.

Soap calls samples

Once the migration process is achieved and validated, the Soap Calls are updated as below:

  • Before the migration: there was no support for Technical account access token.

    POST /nl/jsp/soaprouter.jsp HTTP/1.1
    Host: localhost:8080
    Content-Type: application/soap+xml;
    SOAPAction: "nms:rtEvent#PushEvent"
    charset=utf-8
    
    <?xml version="1.0" encoding="utf-8"?>  <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:nms:rtEvent">
    <soapenv:Header/>
    <soapenv:Body>
        <urn:PushEvent>
            <urn:sessiontoken>SESSION_TOKEN</urn:sessiontoken>
            <urn:domEvent>
                <!--You may enter ANY elements at this point-->
                <rtEvent type="type" email="name@domain.com"/>
            </urn:domEvent>
        </urn:PushEvent>
    </soapenv:Body>
    </soapenv:Envelope>
    
  • After the migration: there is support for Technical account access token. The access token is expected to be supplied in Authorization header as Bearer token. Usage of session token should be ignored here, as shown in the below soap call sample.

    POST /nl/jsp/soaprouter.jsp HTTP/1.1
    Host: localhost:8080
    Content-Type: application/soap+xml;
    SOAPAction: "nms:rtEvent#PushEvent"
    charset=utf-8
    Authorization: Bearer <IMS_Technical_Token_Token>
    
    <?xml version="1.0" encoding="utf-8"?>  <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:nms:rtEvent">
    <soapenv:Header/>
    <soapenv:Body>
        <urn:PushEvent>
            <urn:sessiontoken></urn:sessiontoken>
            <urn:domEvent>
                <!--You may enter ANY elements at this point-->
                <rtEvent type="type" email="name@domain.com"/>
            </urn:domEvent>
        </urn:PushEvent>
    </soapenv:Body>
    </soapenv:Envelope>
    

On this page