Understanding Adobe I/O with AEM

Audience: Adobe Architects, Developers

Read time: 10 minutes 

Let us consider a typical enterprise level digital marketing eco-system containing Adobe solutions.

Consider some typical BAU scenarios in such enterprise eco-system.

1. Second party and third party providers might want to upload data to AAM on regular basis
2. Native android/IOS application wants to access personalized offers from target and target in-turn gets its content from AEM.
3. AEM author wants to push email templates to campaign and offers to target
4. A custom visualization in tableau needs data in a certain format that combines analytics data and campaign success rate from target.
5. Send WhatsApp and email notification to subscribers when a new page is created in microsite built on AEM.

In this big eco-system of applications, security, scalability, performance with which they talk with each other plays a very important role. With the ever-expanding Adobe’s cloud suite of products, there is always a need for one-stop solution, which lets you manage all your API integrations easily. The arrival of Adobe Experience Platform has only amplified this need, as one would certainly require a platform, which lets the developers consume AEP APIs and events easily. Hence, here is my attempt at understanding Adobe I/O, which solves the above-mentioned problems. In this blog, I will try to answer the below questions.

1. What is Adobe I/O?
2. What is Project Firefly?
3. What problems can be solved using Adobe I/O?
4. Should I use Adobe I/O in my project?
5. I think my use-case can use Adobe I/O. How do I use it in AEM?

What is Adobe I/O?

Adobe I/O is a cloud-based gateway to integrate with Adobe API’s, SDK’s and server-less environment that enables developers to easily integrate, extend and customize Adobe’s cloud services.  Adobe I/O is a combination of following components:

1. Integration
2. I/O Events
3. I/O Runtime

Integrations

Adobe I/O standardizes the way Adobe API’s are accessed by other Adobe and custom applications. Developers can manage the connections between their custom applications and all Adobe applications at single place. Following are the advantages of integrating the applications through Adobe I/O

1. Security – OAuth and JWT
2. API Insights – gives an overview of the API’s are being accessed and used
3. Certificates, credentials and tokens can be managed at a single place.

Since the authentication happens over JWT and OAuth, even the custom applications can connect to Adobe I/O

Without Adobe I/O

With Adobe I/O

Consider scenario 4 from our earlier example. Here, there is a need to connect to Analytics as well as Target. Without Adobe I/O, one would have to maintain two credentials and authentication processes to connect to these systems. However, with Adobe I/O, a single credential is sufficient to connect to multiple Adobe Products. We will go into a little depth and try to see how this can be implemented with an example of AEM as a client.

I/O Events

With Adobe I/O, any events that take place in Adobe cloud applications can be consumed by other Adobe or non-adobe applications. Adobe I/O lets you subscribe to many events that occur across Adobe applications like creation of new page, new asset etc. Custom applications can be written to listen to these events and trigger custom actions as mentioned in scenario 5.

I/O Runtime

In the above examples, we have discussed how custom code can extend Adobe products’ functionalities to solve business problems. Naturally, following questions arise out of this.

1. Where does this custom code sit?
2. What is this custom code written with?
3. How do I start to write one?

This is exactly where I/O Runtime comes in. I/O Runtime can be visualized as a server-less platform just like AWS Lambda or Azure Functions. The code can be written in JavaScript and deployed to I/O Runtime. Since this is a server-less technology, the overhead of maintenance, scalability is absent making it a good choice to write applications that consume multiple Adobe APIs. This can also be used as a server to render SPA’s with both client-side and server-side rendering (SSR). There is an easy way to get started with the development of these applications that would be deployed to I/O Runtime – Project Firefly.

What is Project Firefly?

Project firefly is a template, which helps developers quickly develop applications, which consumes Adobe API’s, events. Code thus created can also be readily deployed on I/O runtime. This template injects all Adobe SDK dependencies that the developer would need. Using some simple commands and an interactive process, the project skeleton is created which comes with all required dependencies.

For more details, refer to the link: Getting Started with Project Firefly

Should I use Adobe I/O in my project?

If the answer for any of the below questions is “Yes”, then it is probably worth giving Adobe I/O a consideration.

1. Do you connect to multiple Adobe cloud solution?
2. Do you have business requirement for which you need to combine response of multiple Adobe API’s and provide a more meaningful data?
3. Do you have a requirement where you need to enrich the response of and Adobe API with augmented data from a third party application?
4. Do you need to trigger some custom action when some Adobe product event has occurred?

How do I use Adobe I/O with AEM or a custom application?

Assuming you have already deployed your custom action in I/O runtime using the project firefly’s Getting Started link, this section describes how one can authenticate and use the action in client application.

Integration with AEM

Integration of AEM and I/O Runtime custom action involves following steps:

1. Creation of public and private key pair
2. Uploading private key to AEM
3. Uploading public key to Adobe I/O
4. Configuring Access Token Provider in AEM.
5. Injecting Access token provider as a dependency in client code.

Steps 1,2 and 3 are well documented in this link.

Step 4: Configuring Access Token Provider in AEM

4.1 Create a new “Adobe Granite Access Token Provider” configuration in AEM OSGi Configuration Manager

4.2 Configure the values from credentials section of Console.adobe.io

4.3 KeyPair Alias: this is the same alias that you used for generating the key and while associating it to the user(while uploading to AEM)

4.4 Uncheck “Cache Access Tokens”

4.5 Provide any name in “Name of token request customizer implementation”. 

4.6 Save the configuration

4.7 Add new “Adobe Granite OAuth IMS Request Customizer” configuration.

4.8 Provide the same name provided in Step 4.5

Step 5: Injecting Access token provider as a dependency in client code

5.1 Inject Access token provider dependency in the code where you want to call your custom action.

5.2 Write bind and unbind methods

5.3 Loop thru the available access token provider and call the appropriate one.

There are certain points to be noted with respect to the user.

• Resource resolver should be initialized with the same user against which the private key was uploaded in step 2.
• For some reasons, this code gives an error for service users.

5.4 The token thus obtained can be used in authorization header to make a call to custom action deployed in I/O runtime. This has to be a HTTPS connection. URL to your custom action will be printed in the logs when you start your firefly app with command “aio app run”.

Integration with Non-AEM applications

Access token can be generated for non-AEM applications in a similar way through following steps:

1. Creation of public and private key pair
2. Uploading public key to Adobe I/O
3. Construct JWT and sign it with private key.
4. Call Access Token Request API https://ims-na1.adobelogin.com/ims/exchange/jwt with signed JWT.
5. Use the token obtained to make call to custom action.

Conclusion

Using Adobe I/O, with proper architecture, maintenance cost and total cost of ownership can be reduced in an Adobe heavy eco-system and can prove beneficial in long run.