API calls (via JSSP) vs feed file | Community
Skip to main content
S
supratim320
Level 5
April 5, 2023
Solved

API calls (via JSSP) vs feed file

  • April 5, 2023
  • 2 replies
  • 2538 views

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)

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 david--garcia

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#bITInfrastructureResourcesbyActiveProfilesTiersb

 

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.

 

 

2 replies

Marcel_Szimonisz
Community Advisor
Marcel_SzimoniszCommunity Advisor
Community Advisor
April 5, 2023

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

S
supratim320Author
Level 5
April 5, 2023

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
Community Advisor
Marcel_SzimoniszCommunity Advisor
Community Advisor
April 5, 2023

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-web-service-call-via-rest/td-p/448347

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
    david--garcia
    Level 10
    April 5, 2023

    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.

    S
    supratim320Author
    Level 5
    April 5, 2023

    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
      david--garciaAccepted solution
      Level 10
      April 5, 2023

      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#bITInfrastructureResourcesbyActiveProfilesTiersb

       

      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.

       

       

      Terms & ConditionsAccessibility statement

      Loading footer...