I need help to implement below

SagarGadakh
Tera Contributor

yesterday

Hello.

 

I need help to implement below. Please get in touch with me if anyone can help.

 

Deliver end to end integration using integration hub

oAuth token refresh

Delta logic load

Error Queue + retry mechanism

Monitoring dashboard

0 Helpfuls
  • 193 Views
1 REPLY 1

Itallo Brandão
Giga Guru

yesterday

Hi @SagarGadakh ,


That is a robust set of requirements for an Enterprise-grade integration. Since we cannot directly "get in touch," here is the architectural blueprint to implement each of those components using Integration Hub best practices.


1. OAuth Token Refresh (Native)

Do not write script for this. ServiceNow handles OAuth 2.0 token management natively.

  • Implementation:

    1. Navigate to System OAuth > Application Registry.

    2. Create a new entry for your external provider.

    3. Go to Connections & Credentials > Credentials and create an OAuth 2.0 Credential record linking to that registry.

    4. Result: Integration Hub will automatically request a new access token using the Refresh Token when the current one expires. You just use the Alias in your Action.


2. Delta Logic Load (The "Watermark" Pattern)

To only fetch changed records, you need to store the "Last Run Date".

  • Implementation:

    1. Storage: Create a System Property (e.g., my.integration.last_run).

    2. Flow Logic:

      • Action 1: Get the value of this property.

      • Action 2 (REST Step): Use this date in your query parameters (e.g., ?updated_since=[Action1.Value]).

      • Action 3 (Post-Processing): If the integration runs successfully, update the property with the current timestamp (gs.nowDateTime()).

3. Error Queue + Retry Mechanism

For a true "Retry Queue," relying solely on Flow Error Handler is often not enough. You should use a Staging/Queue Table.

  • Architecture:

    • Table: Create a custom table (e.g., u_int_incident_queue) with fields: Payload, Status (Pending, Processing, Error, Complete), Retry Count, and Error Message.

    • Flow A (Fetcher): Gets data from source -> Creates records in u_int_incident_queue (Status = Pending).

    • Flow B (Processor): Triggered when a Queue record is created.

      • Tries to process the record.

      • Success: Sets Status to 'Complete'.

      • Error Handler: Catches failure -> Sets Status to 'Error' -> Increments Retry Count -> Logs error message.

    • Retry Logic: Create a Scheduled Job that runs every 30 mins:

      • Query records where Status = Error AND Retry Count < 3.

      • Resets Status to Pending (which re-triggers Flow B).


4. Monitoring Dashboard

Since you built the Queue Table in step 3, monitoring becomes easy.

  • Implementation:

    1. Create a ServiceNow Dashboard.

    2. Add Reports based on your u_int_incident_queue table.

    3. Widgets needed:

      • "Integration Errors Today" (List view).

      • "Success Rate" (Pie chart: Complete vs Error).

      • "Average Processing Time".

This architecture ensures that if the target system goes down, you don't lose data; it just sits in your Error Queue waiting for the retry job.

 

If this architectural guide helps you move forward, please mark it as Accepted Solution.


Best regards,
Brandão.

0 Helpfuls