ÃÛ¶¹ÊÓƵ

DocumentationCampaignCampaign v8 Documentation

Campaign API staging mechanism

Last update: Thu Sep 26 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

CREATED FOR:

  • Intermediate
  • Developer

In the context of an Enterprise (FFDA) deployment, blasting unitary calls is not recommended with regards to performances (latency & concurrency). Unless you are sending extremely low volume, batch operation must be used. In order to improve performance, ingestion APIs are redirected to the local database.

Campaign staging capability is enabled by default on some built-in schemas. We can also enable it on any custom schema. Staging mechanism in a nutshell:

  • Data schema structure is duplicated into the local staging table
  • New APIs dedicated for data ingestion flow directly into the local staging table. Learn more
  • A scheduled workflow triggers every hour and synchronize data back to the Cloud Database. Learn more

Some built-in schemas are Staged by default, such as nmsSubscriptionRcp, nmsAppSubscriptionRcp, nmsRecipient.

Campaign Classic v7 APIs are still available but cannot benefit from this new Staging mechanism: API calls flow to directly directly to the Cloud database. ÃÛ¶¹ÊÓƵ recommends to use new Staging mechanism as much as possible to reduce overall pressure and latency on Campaign Cloud database.

CAUTION

  • With this new mechanism, data synchronization for channel optout, subscriptions, unsubscriptions or mobile registration is now asynchronous.

  • Staging only applies for schemas stored on Cloud Database. Do not enable staging on replicated schemas. Do not enable Staging on local schemas. Do not enable Staging on a Staged schema

Implementation steps implement-staging

To implement Campaign staging mechanism on a specific table, follow the steps below:

  1. Create a sample custom schema on Campaign Cloud database. No staging enabled at this step.

    code language-none 
    <srcSchema _cs="Sample Table (dem)" created="YYYY-DD-MM"
        entitySchema="xtk:srcSchema" img="xtk:schema.png" label="Sample Table"
        lastModified="YYYY-DD-MM HH:MM:SS.TZ" mappingType="sql" md5="XXX"
        modifiedBy-id="0" name="sampleTable" namespace="dem" xtkschema="xtk:srcSchema">
<element autopk="true" autouuid="true" dataSource="nms:extAccount:ffda" label="Sample Table"
        name="sampleTable">
    <attribute label="Test Col 1" length="255" name="testcol1" type="string"/>
    <attribute label="Test Col 2" length="255" name="testcol2" type="string"/>
</element>
</srcSchema>

    Learn more about custom schema creation in this page.

  2. Save and update the database structure. Learn more

  3. Enable the staging mechanism in the schema definition by adding the ²¹³Ü³Ù´Ç³§³Ù²µ=“t°ù³Ü±ð†parameter.

    code language-none 
    <srcSchema _cs="Sample Table (dem)" "YYYY-DD-MM"
        entitySchema="xtk:srcSchema" img="xtk:schema.png" label="Sample Table"
        lastModified="YYYY-DD-MM HH:MM:SS.TZ" mappingType="sql" md5="XXX"
        modifiedBy-id="0" name="sampleTable" namespace="dem" xtkschema="xtk:srcSchema">
<element autoStg="true" autopk="true" autouuid="true" dataSource="nms:extAccount:ffda" label="Sample Table"
        name="sampleTable">
    <attribute label="Test Col 1" length="255" name="testcol1" type="string"/>
    <attribute label="Test Col 2" length="255" name="testcol2" type="string"/>
</element>
</srcSchema>

  4. Save the modification. A new staging schema is available, which is a local copy of the initial schema.

  5. Update the database structure. The staging table will be created on Campaign local database.

recommendation-more-help
35662671-8e3d-4f04-a092-029a056c566b