Custom Response In Message Center

[ShineVv0823]

Hi Team,

is it possible to send custom response from Adobe Campaign for Message Center SOAP API call request that is made to Adobe Campaign. 

The vendor that is triggering the SOAP API call to Adobe Campaign for Transactional SMS and Email, is requesting us send to a response back to them like status: "success"; for now Adobe Sends a <plId xsi:type='xsd:long'>72017594012033137</plId>

as default response.

Could someone help me out?

Thanks,

Shine v.v 

[Manoj_Kumar_]

Hello @ShineVv0823 

You can create a dynamic JSSP page and write a function to call the Message center API in the JSSP page.

Depending on the response of the MC API. you will return a response of success:true or false.

Now, On your vendor side, you will ask them to post data to your dynamic JSSP page instead of MC API.

You Flow will look like this

Vendor Website -> Data Post -> Adobe CAmpaign JSSP Page -> Message API CALL -> Return response.

[Denis_Bozonnet]

Hi @ShineVv0823  and @Manoj_Kumar_ 

Sadly you can't do the suggested as you are not authorised to deploy custom code on the RT execution instances, so the short answer to te request is no, you can't override the response from the SOAP request.

The logic would to be done in a wrapper on the caller side. Besides, on the client side, you would have to deal with error sent back from the SOAP request (via the fault element and the authentication token, so having a wrapper on the caller system does perfect sense too,

Sadly on Campaign side, due to the access restriction in place for RT execution instances, you can't build such wrapper in ACC.

Hope this helps even if it is not the answer you were expecting,

Thanks

Denis

[Manoj_Kumar_]

Hello @Denis_Bozonnet 

In this solution, we won't be deploying any custom code on the RT instance. The JSSP page will be live on the MKT instance.

JSSP on the MKT instance will call the RT instance API.

[Denis_Bozonnet · Accepted solution]

Hi @Manoj_Kumar_ and @ShineVv0823 

true technically you forgot that the marketing side of API has drastic limitations in term of volume (20,000 a day to 50,000  a day depending your package) meaning that you solution technically possible is not scalable. 

i strongly suggest you design a global solution within the product boundaries to have a scalable system as a whole. In your use case, the logic will have to be done on the 3rd party system calling the Transactional API. We all know developers don’t like SOAP request anymore however if they want a scalable and stable solution they should work within the product boundaries. 

if you persist in your approach, we will need to purchase extra API capacities to support your expected volume (initial and growth). 

we’re seeing far too often product boundaries ignored and systems run into trouble down the line and require significant rework to put them back in the boundaries. 

we can’t prevent what you’re doing however make sure you document the consequences as you would move to 50,000 an hour to 20,000 to 50,000 a day it’s not quite the same and you need to design stable, scalable solution. 

Just my advise on the subject,

Hope this helps

Denis. . 

[Manoj_Kumar_]

@Denis_Bozonnet  Yes, you are correct. Engine calls are something that @ShineVv0823 will have to consider for this solution.

[ShineVv0823]

Thank You @Manoj_Kumar_ , @Denis_Bozonnet , thank you so much for your inputs. This really helps.

Thanks,

Shine v.v