0

Is there any practical way to write JavaScript functions such that the same code can be executed in BOTH a Landing Page written in AMPscript AND SSJS executed on the server (other than copying the same code into both, of course)?

2
  • Can you please explain your use case? Do you mean a content block that would work in any landing page, regardless whether it’s written in AMPscript or SSJS - because I’m not sure what the problem would be with that?
    – zuzannamj
    Commented Oct 14 at 18:46
  • I assume this is for executing backend ampscript/ssjs in a front end javascript, e.g. for ajax form submission or similar? It can for sure be done, like in this example. If this isn't what you are after, do let us know. Commented Oct 14 at 21:09

1 Answer 1

1

If you mean use client side and server side script interchangeably - it wont work

AMPScript / SSJS are serverside, "normal" JS is clientside.

== If I understand correctly - centralize code? Then the answer likely is %%=ContentBlockByKey("myCodeSnippet")=%%.

Write a codesnippet, give it the customer key myCodeSnippet and call it from whatever place you want that supports AMPScript. You can also leverage this from SSJS scripts via Platform.Function.ContentBlockByKey().

In codesnippets you can mix / match AMPScript and SSJS, and trade variables back and forth with Variable.GetValue() / Variable.SetValue(), which isn't great for performance at scale, but works fine generally.

You can place that ContentBlockByKey() like you would a function call, yet if you talk about proper function things: You cannot send arguments into JS functions from AMPscript or get a proper "return" from the ContentBlockByKey(). AMPscript simply does not work that way. AMPScript is just interpreted top to bottom, meaning your JS code invoked via ContentBlock should also be written like that.

That "dual use" has its limits though. Note that cloudpages and emails are different execution contexts, i.e. they have slight differences. Examples:

  • Some things might work differently (e.g. not all personalization strings might work the same, though most will)

  • Cloudpages might block some things that work in script activities (and - even more so - cloudpage preview). This can give a lot of false negatives where published pages allow what the cloudpage blocks.

  • You have to use are different AMPScript functions for Data extension manipulation (e.g. see UpsertDE / UpsertData) for the different contexts.

So you'd better cross-check your code everywhere you intend to use it until you have some general idea on what works where.

  • you'd execute your times code potentially millions of times in a minute when sending a large email, and your cloudpage would get much more distributed load, and a script activity would run once per hour. Which is why especially in emails, the performance heavy SSJS "Core" (= Platform.Load("Core",1)) library is best avoided for this sort of thing - it will not go down well in large email sendouts.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .