Calculate new Recipient field and use it into Deliveries | Community
Skip to main content
Y
yetanother_andrey
Level 3
July 18, 2018
Solved

Calculate new Recipient field and use it into Deliveries

  • July 18, 2018
  • 4 replies
  • 3481 views

Couple of days ago users came to me and asked if I could help them with an interesting case. Days passed, and I still don't have any idea.

I need Adobe Campaign to allow users to insert Tokens into personalized links inside Deliveries (emails for now). Token is a value generated by JavaScript code developed in our company, this code requires our internal Id of the customer as an input, and this id is already stored into our Adobe Campaign DB.

By the way, part of this code implements AES encryption with CBC mode and padding, I would love to use AC internal functions for that, but AC doesn't support controlled AES encryption, DES only.

And here comes the question: I have JavaScript code inside Adobe Campaign and I have all required data in Adobe Campaign. How to send an email?

1. I can create new attribute for nms:recipient to store Token. But then I'll have to run JavaScript code against my entire DB and will have to re-run it for all new customers. Or I can spend and unknown amount of time to translate Token generation code from JavaScript to e.g. PostgreSQL function and run it against my DB. Both options can lead to unknown risks with unknown chance of success.

2. (What I thought must be a solution, but...) I can use a combination of Personalization Block, and nms:recipient properties available as Personalization Fields. This one failed because I can't use loadLibrary() inside Personalization Block or Delivery. They both use JavaScript engine to compile personalization, but seems like it's a different engine with no access to AC API/DB (I'm wondering how AC passes personalization into email?).

3. I can't use Typology Rule (Control) for this, because even at the end of analysis Delivery contains <%= recipient.email %> but not exact email. (Is MTA actually is the place where all <%= %> blocks execute?)

What else can I try here?

florentlb​

Jean-Serge Biron​

Vipul Raghav​

Adhiyan​

I'm summoning you, guys! (:

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Jean-Serge_Biro

Hi Andrey,

First of all, AES algorithm is supported through the standard Adobe Campaign API, see documentation JSAPI.chm for cryptString and decryptString, in most of objects/process of AC. And also the AESEncrypt function of the XTK, used by calculated cryptString in nms:recipient schema (see below).

Yes, you are right, 3DES is supported but deprecated.

Then, first solution of implementing a specific attribute in the custom extension of nms:recipient can be considered if your main reason is performance matter, you won't calculate again and again the AES values, such as a calculated attribute in the schema (2nd alternative below). The drawback is inserting the new values for new records, with your ETL tool or your AC workflow.


However calculated attribute works fine as well, if you consider some cases it can avoid disk consumption (but most often storage is not a problem nowadays).

And it is dynamically calculated, no script for new records to fill the attribute value.
And since you don't have to search/sort/transform, etc on this kind of field/attribute, indeed, calculated value can be considered in your use case.

This method is used for nms:recipient.@cryptedId (the AES value of nms:recipient.@id), the expression in the nms:recipient schema is:

expr="AESEncrypt(@id)

See for instance another example,  nms:recipient.@domain with its expr="GetEmailDomain([@email])" in the nms:recipient schema.

You can use xpath or XTK functions to write the expr.

The third solution is to not change/extend the nms:recipient schema, but achieving your specific calculation in the workflow itself, adding extra elements/attributes to your dataset.

Eventually, the choice depends on use cases, all these 3 approaches are valuable.

Extending the schema: there are no risks at all, thanks to extension mechanism of Adobe Campaign.

Afterwards, you can select the custom attribute in your delivery personalisation directly with targetData or directly, depending on the choice taken; if you extended the schema, directly; or with targetData if you add the AES calculated value with other workflow activities (enrichment, Javascript).


Hope this can help.


Regards

J-Serge

4 replies

Jean-Serge_Biro
Jean-Serge_BiroAccepted solution
Level 10
August 6, 2018

Hi Andrey,

First of all, AES algorithm is supported through the standard Adobe Campaign API, see documentation JSAPI.chm for cryptString and decryptString, in most of objects/process of AC. And also the AESEncrypt function of the XTK, used by calculated cryptString in nms:recipient schema (see below).

Yes, you are right, 3DES is supported but deprecated.

Then, first solution of implementing a specific attribute in the custom extension of nms:recipient can be considered if your main reason is performance matter, you won't calculate again and again the AES values, such as a calculated attribute in the schema (2nd alternative below). The drawback is inserting the new values for new records, with your ETL tool or your AC workflow.


However calculated attribute works fine as well, if you consider some cases it can avoid disk consumption (but most often storage is not a problem nowadays).

And it is dynamically calculated, no script for new records to fill the attribute value.
And since you don't have to search/sort/transform, etc on this kind of field/attribute, indeed, calculated value can be considered in your use case.

This method is used for nms:recipient.@cryptedId (the AES value of nms:recipient.@id), the expression in the nms:recipient schema is:

expr="AESEncrypt(@id)

See for instance another example,  nms:recipient.@domain with its expr="GetEmailDomain([@email])" in the nms:recipient schema.

You can use xpath or XTK functions to write the expr.

The third solution is to not change/extend the nms:recipient schema, but achieving your specific calculation in the workflow itself, adding extra elements/attributes to your dataset.

Eventually, the choice depends on use cases, all these 3 approaches are valuable.

Extending the schema: there are no risks at all, thanks to extension mechanism of Adobe Campaign.

Afterwards, you can select the custom attribute in your delivery personalisation directly with targetData or directly, depending on the choice taken; if you extended the schema, directly; or with targetData if you add the AES calculated value with other workflow activities (enrichment, Javascript).


Hope this can help.


Regards

J-Serge

Y
yetanother_andreyAuthor
Level 3
August 6, 2018

Hi Jean-Serge Biron

I don't have access to my Adobe Campaign or JSAPI doc right now - may I kindly ask you to check whether it is possible to use HMAC and CBC with pkcs padding?

Thanks a lot!

Andrey

Jean-Serge_Biro
Jean-Serge_Biro
Level 10
August 7, 2018

Hi Andrey,

The JSAPI.chm doc only mentions CBC and padding, but not all HMAC (nor GCM) for integrity checks.

cryptography - When to use HMAC alongside AES? - Information Security Stack Exchange

Galois/Counter Mode - Wikipedia

I would be glad if Adobe Campaign R&D could read this forum post and answer by their own, perhaps there is a support elsewhere or it is planned.
My own skills are limited on current documentation of Adobe Campaign 6.1.1/7.0, there are possibly other ways to achieve what you need, if calculated expression in schema AESEncrypt or JSAPI cryptString/decryptString functions are not valuable for you.

Regards
J-Serge

Jean-Serge_Biro
Jean-Serge_Biro
Level 10
August 7, 2018

By the way, I am reading just now the Adobe Campaign Classic (v6/v7) and Standard (ACS) release notes, and the decryptString function is deprecated since build 8947 (last build, released on July 2018), still usable for cryptedId to be decrypted in webApp but replaced for password use by decryptPassword (not your use case anyway).

Adobe Campaign Release Notes

Terms & ConditionsAccessibility statement

Loading footer...