API calls (via JSSP) vs feed file

[supratim320]

Hi Everyone,

We are currently designing a solution where ecommerce website will be integrated with Campaign classic. We are using jssp to load order and customer data.

However, mostly used data loading process in Adobe campaign is feed file mostly. So, my question:

a. Is there any drawback of using jssp vs feed file

b. Is there any volumetric capacity to keep in mind for jssp usage vs feed file

c. Is there any security aspect to keep in mind in jssp way

Please let me know further any upside or downside of using jssp vs feed file in live project. Since it is an ecommerce website, we are expecting large volume (100k/hr approx)

[Marcel_Szimonisz]

Hello @supratim320 ,
normally you do either file load or in real time use of built it or custom schema SOAP methods for any CRUD operations. This can be scaled up by adding load balancers and new web server instances

Marcel

[supratim320]

Thank you for your reply @Marcel_Szimonisz , however, we are encountering a real time use case where the source system wants to use Rest call in json format (rather than feed file or SOAP) - this is why we are looking to explore JSSP option.

I understand your suggestion, but just in case, I have to do this in JSSP way, do you see any particular problem or challenge that JSSP might pose or any security issue

[Marcel_Szimonisz]

Hello @supratim320 ,

i do not see any issue. You will be using JSSP accepting POST requests? Kind of creating REST interface? With use of

NL.API as described here?
https://experienceleaguecommunities.adobe.com/t5/adobe-campaign-classic-questions/campaign-classic-w...

If yes than all is good as you will have to reuse the adobe campaign security features __securitytoken that you get by calling xtk:session#logon method.

Marcel Szimonisz

[david--garcia]

Adobe best practice guides do not recommend to use APIs for batch/bulk data consumption due to performance reasons, you are left with FDA, flat files, or direct to database data loads.

[supratim320]

Thank you for the response @david--garcia , I understand the performance reasons could be dependent on the server configuration, however, is there any volumetric data available on this limitation so that we could have the guardrail discussion with the corresponding team?

[david--garcia · Accepted solution]

I think before continuing down this route, you may want to take into consideration what your contractual license constraints are in terms of engine calls:  Engine Call means a server call that starts real-time processing on server side for the extraction of data, such as data relating to surveys, WebApps, JSSP, APIs, mobile app registrations, etc. Engine Calls must be licensed in packs of 5,000 Engine Calls per day.

You can then estimate the number of records you want to transfer over API and measure/monitor performance indicators to conclude how many records/bytes can be transferred in the less number of calls without impacting other areas of campaign, and specially during peak hours or during other data load intensive operations.

If you are expecting to trasfer up to 100k records per hour, that would be around 27-30 records per second to consume every 1 hour, the contract may mention what the limitation is per seconds. https://helpx.adobe.com/legal/product-descriptions/adobe-campaign-classic---product-description.html...

I would start by calculating how many records/bytes I can transfer per engine call without noticing too much impact on the server/db/services and start scaling resources for future proofing as well as add peak performance buffer.

At one point I was only updating a single flag over API and was sending 10k records to update per call, but that was just with 1 flag, and performance was fine.