Each time you want to republish the updated Cloud Page, you have to go through the Preview window (that load the whole code in POST method context), confirm it and go to the page via URL to see the GET method context. And those tests - across your team and over time - stack up. During debugging, you might hit quite a lot of those. Each view of the Cloud Page costs one Super Message. It has, however, two flaws that, in some scenarios, might guide you to a different solution. It is a great way, as it allows you to easily leverage SSJS for the backend and HTML/CSS/JavaScript for the frontend. The most popular recommendation is Cloud Page - write or paste the SSJS code there, publish and check whether it is working correctly. However, only a few of those are really good to test your code, as only some of them provide access to methods mentioned later in the article. In all of the above cases, you might write more complex logic that will be error-prone and in need of debugging. Emails and other communication (Email Studio / Mobile Studio / Content Builder).Code Resources (Web Studio -> Content Builder).The language is useful in many places within the Marketing Cloud ecosystem. How to survive those?īefore diving deep into errors, let's talk about where to write the SSJS. And if you beat it and go forward with the code and official documentation, you will fall in love with unexpected errors in functions and API responses. When you start working with programmatic languages in Salesforce Marketing Cloud, you will quickly become close friends with the Error 500 page. To catch, or not to catch, that is debugging.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |