Skip to main content

Prerequisites

Before initiating the configuration, ensure you have the following credentials and connectivity in place:
  • Make sure that you have followed Get started with connectors.
  • Microsoft Dataverse access: An active Dataverse environment and required API permissions.
  • Network connectivity: Confirmed routing between the Dataverse environment and the Grand Central (GC) iPaaS.
  • Environment details: The following table shows the environment variables you need from Dataverse to configure the connector:
KeyDescription
dataverse.serviceUriThe base URL to access the Dataverse API
dataverse.resourcePathThe resource path for the Dataverse API

Configuration guide

Follow these steps to initialize and authorize your Microsoft Dataverse connector.

1. Establish connectivity

Share the following details with the Grand Central team to establish secure connectivity between Grand Central and Dataverse:
  • Environment details: serviceUri and any required IP ranges for allowlisting.

2. Environment configuration

To initialize the Dataverse connector, define specific environment variables within your gc-applications-live repository. Store these variables in the values.yaml file for outbound requests and inbound-values.yaml for inbound webhook events.
Security note: Do not commit client secrets or certificates to the values.yaml files. Use the platform secret management process.

Define outbound parameters

The following table shows variables that authorize and route requests sent from Grand Central to Dataverse:
KeyDescription
dataverse.serviceUriTarget API endpoint for Dataverse.
dataverse.resourcePathResource path for Dataverse requests.
retryFlagSet to true to enable automatic request retries.
Below is a sample values.yaml:
# Sample Dataverse outbound environment configuration
connector:
  properties:
    retryFlag: true
    dataverse.serviceUri: https://your-org.crm.dynamics.com
    dataverse.resourcePath: /api/data/v9.2

  traits:
    knativeservice:
      # IMPORTANT: Cost-related. Keeping minScale >0 causes continuous cost even when idle.
      # With minScale: 0, each request grants 30 min uptime (extended if new requests arrive).
      # Use >0 only if hot start is required, and reset to 0 afterward to avoid unnecessary cost.
      minScale: 0
    logging:
      # DEBUG adds significant log output during startup and runtime.
      # This can noticeably slow down starts due to extra logging work and I/O.
      # Use only for troubleshooting and disable when not needed.
      level: INFO
Below is the path where the values.yaml file needs to be placed:
├── iPaaS
   └── azure/runtimes
       ├── dev
       |    └── values
       |       └── gc-dataverse
       |            └── values.yaml
       └── test
            └── values
                └── gc-dataverse
                    └── values.yaml

Define inbound/webhook parameters

Configure how Grand Central receives asynchronous updates from Dataverse to GC. Dataverse webhooks can be configured for create, update, and delete events on specific tables. Register your GC inbound endpoint as a webhook in Dataverse, and filter the events to only the tables and columns you need. The following table shows the inbound connector parameters:
KeyDescription
asb.event.versionVersion of the Async Service Bridge (ASB) schema.
asb.producer.apiUriThe callback URI for receiving incoming events.
asb.event.topicThe ASB topic to send messages.
asb.event.typeThe ASB event type to send messages.
asb.event.sourceThe ASB source to send messages.
Below is a sample inbound-values.yaml:
# Sample Dataverse inbound environment configuration
connector:
  customLabels:
    app.gcservices.io/synchub-enabled: "true"
    app.gcservices.io/synchub-type: "producer"
  properties:
    retryFlag: true
    asb.event.type: com.backbase.party.event.spec.v1.PartyUpdateEvent
    asb.event.source: com.backbase.crm
    asb.event.version: 1.0.0
    asb.event.topic: party-updates
    asb.producer.apiUri: http://asb-producer-v0.synchub-producer.svc.cluster.local
  traits:
    knativeservice:
      # IMPORTANT: Cost-related. Keeping minScale >0 causes continuous cost even when idle.
      # With minScale: 0, each request grants 30 min uptime (extended if new requests arrive).
      # Use >0 only if hot start is required, and reset to 0 afterward to avoid unnecessary cost.
      minScale: 0
    logging:
      # DEBUG adds significant log output during startup and runtime.
      # This can noticeably slow down starts due to extra logging work and I/O.
      # Use only for troubleshooting and disable when not needed.
      level: INFO
Below is the path where the inbound-values.yaml file needs to be placed:
├── iPaaS
   └── azure/runtimes
       ├── dev
       |    └── values
       |       └── gc-dataverse
       |            └── inbound-values.yaml
       └── test
            └── values
                └── gc-dataverse
                    └── inbound-values.yaml

Testing your integration

To access the Dataverse connector, you must include your Grand Central subscription key in the request header. If you do not have a key, contact the Grand Central Support Team to have one provisioned.
KeyValue
api-key<your_subscription_key>
Webhook registration: To process asynchronous updates, register your environment callback URL in your Dataverse webhook configuration.
Test the API using the Postman Collection.

Troubleshooting

If your connector isn’t responding as expected, check these common scenarios.
Cause: The Grand Central (GC) gateway cannot establish a handshake with the Dataverse endpoint. This typically indicates an upstream service outage at Dataverse or a network routing failure.Solution: Verify the operational status of the Dataverse environment. If the service is operational, contact GC Support.
Cause: The request to Dataverse timed out before receiving a response. This may indicate high latency or an unresponsive endpoint.Solution: Verify the operational status of the Dataverse environment. If the service is operational, contact GC Support.
Cause: The OAuth application credentials provided during setup are incorrect or expired.Solution: Re-verify your Dataverse app registration credentials and contact the GC team to update the connection.
Cause: The number of incoming requests has exceeded the defined threshold for your subscription tier. This “429 Too Many Requests” response is a protective measure to ensure platform stability.Solution: Review your application’s request patterns to identify unexpected spikes. If your business requirements have evolved and you require a higher throughput, contact the Grand Central Team to request an adjustment to your APIM rate limit policy.

Need more help?

Contact support

Reach out to the Grand Central team for assistance with environment setup or rate limit increases.