iSchedule

iSchedule allows staff to schedule iImport or iUpdate tasks. iSchedule supports daily, monthly, or hourly execution. There are many possible ways to use iSchedule - common examples include:

  • Schedule an iUpdate task to run on a recurring basis
  • Schedule an iUpdate or iImport task to run after hours

Creating a Scheduled Task 

During the Mapping step, after completing mappings and selecting your options, select Schedule as Task.

Creating or editing a Task Page

After clicking Schedule as Task or the Edit button on an existing task, you are taken to the Edit Task page. Do the following:

  1. (Required) Add a name for the scheduled task.
  2. (Optional) Add a description for the task.
  3. Determine the number of times a job can fail before being automatically disabled.
  4. The Crontab Schedule (UTC) enables you to schedule a task either as a one-time event or on a recurring basis.
  5. Disable or Enable your scheduled task:
    1. Click the Schedule Builder button on the right. This opens a dialog box like the one below.
    2. Click Recurring to schedule a task to run repeatedly on a set schedule.
    3. Click One-Time to schedule a task to run a single time.

      4. Note: By default, times are in UTC time.

    4. Once the schedule isset, click Save.

The task appears in the Manage Tasks list. From here, view  the listing.

Note: You also have the ability to sort on the column headers. Sort by Name, Last Run, Updated By, and more.

The following actions are available:

  • Edit Task Properties
  • Edit Mappings
  • Delete Task
  • Run Task Now

Disable an Active Scheduled Task

To disable an active scheduled task:

  1. Go to iSchedule and locate the job to disable.
  2. Click he yellow Edit Task Properties button under the Actions row.
  3. Disable the Is Enabled option.
  4. Click Save.

Using Webhooks and HTTP Triggers

iSchedule makes it possible to remotely trigger a task.

Webhook information

To view webhook or trigger information for a task, click the information icon next to the task Name. Webhook information can be found under the POST Webhook URLs header.

Standard (Fire-and-Forget) URL

This webhook type will start the corresponding iUpdate task. It will return an error only if there was an issue initializing or starting the job.

Note: This is the URL with original, unchanged behavior from previous versions of iDMS.

This webhook type will not:

  • Wait for the iUpdate job to finish.
  • Indicate whether the iUpdate job succeeded or failed.
  • Report the number of records retrieved and/or processed.

Review the following examples:

Power Automate

Using the HTTP action:

cURL

Copy 
curl -X POST https://iimport.cloud.csiinc.com/task/execute/00000000-0000-0000-0000-000000000000

Raw HTTP

Copy 
POST /task/execute/00000000-0000-0000-0000-000000000000 HTTP/1.1
Host: iimport.cloud.csiinc.com
User-Agent: example-documentation/1.0
Content-Length: 0

jQuery

The following jQuery is written to execute the task on page load:

Copy 
<script>jQuery(document).ready(function() {
    const runTask = async () => {
        const iMISID = JSON.parse(document.getElementById("__ClientContext").value).selectedPartyId;
        const res = await fetch("https://iimport.cloud.csiinc.com/task/execute/555e1a89-5d7d-4daf-ae0e-sampleGUID", {
            method: "POST",
            body: JSON.stringify({
                QueryParameters: {
                    ID: iMISID,
                },
            }),
            headers: {
                "Content-type": "application/json;",
            },
        });
        const data = await res.json();
        console.log(data);
    };
    runTask();
});
</script>

Asynchronous Polling URL

This URL provides the newer “Wait for Completion” functionality in iDMS, supporting iUpdate job chaining and enhanced integration with external tools such as Microsoft Power Automate.

This webhook type starts the corresponding iUpdate task and returns a special HTTP status code indicating that the job has begun, along with a location to poll for status updates. The endpoint also provides a notification when the job is complete.

This webhook will not:

  • Wait for the job to complete before returning the HTTP response.

    • Note: Jobs can take much longer than the maximum HTTP timeout value.

HTTP Polling Overview

Using the HTTP polling endpoint requires an application or tool that supports the Asynchronous Request-Response Pattern, or a custom script or application that implements this pattern.

The asynchronous polling pattern can be summarized as:

  1. Making a standard webhook POST call to the polling endpoint, as with other webhooks.
  2. A 202 Accepted response is returned with two key headers: Location and Retry-After.
    • Location: Specifies where to poll for the job status.
    • Retry-After: Specifies how often to poll.
  3. Send a GET request to the polling endpoint. The response will be one of two possible outcomes:
    • 202 Accepted: Indicates that the job has not yet completed.
      • The JSON body of this response will contain the job status (typically "in progress") as well as the percentage completion and some other useful status values.
      • The application should re-issue this same GET request after the specified Retry-After interval (typically 30 seconds).
    • 200 OK: Indicates the job has completed.
      • The JSON body indicates if the job was successful or not, and contains statistics about the number of records processed.
      • The application should stop polling after receiving this response. Subsequent requests to this endpoint will always return the same JSON response.

Examples

The following are examples:

Power Automate

  1. Use the HTTP action:

  2. Click the menu and select Settings.

  3. Ensure that Asynchronous Pattern is on.

When using this method with Power Automate, the workflow will not proceed to the next action until the iDMS job has completed, allowing multiple iDMS jobs to be chained in sequence.

Note: Intermediate polling steps (the “202 Accepted” requests) are not displayed in Power Automate. The action remains in an executing or waiting state until the iDMS job finishes, with polling handled internally.

In the example below, the task took 11 minutes to process, and the workflow proceeded to the next step only after the iDMS job was complete.

C#

Copy 
using System;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
 var httpClient = new HttpClient();
 // Start the job
var jobStartResponse = await httpClient.PostAsync("https://iimport.cloud.csiinc.com/task/executepolling/00000000-0000-0000-0000-000000000000", null);
 // Get the polling URL and polling interval from the response headers
var pollingUrl = jobStartResponse.Headers.Location;
var pollingInterval = jobStartResponse.Headers.RetryAfter.Delta ?? TimeSpan.FromSeconds(30);
 HttpResponseMessage lastResponse = default;
 do
{
    // If we are still in polling mode, then wait
    if (lastResponse is null or { StatusCode: HttpStatusCode.Accepted })
    {
        await Task.Delay(pollingInterval);
        // or Thread.Sleep()
    }
         // Issue a request to fetch the latest status
    lastResponse = await httpClient.GetAsync(pollingUrl);
     // Loop while we are still receiving 202 Accepted responses
} while (lastResponse.StatusCode == HttpStatusCode.Accepted);
  var jsonJobStatus = await lastResponse.Content.ReadAsStringAsync();
 // Deserialize or read properties from the JSON response...

cURL

Copy 
curl -X POST https://iimport.cloud.csiinc.com/task/executepolling/00000000-0000-0000-0000-000000000000
# Receive 202 Accepted
curl https://iimport.cloud.csiinc.com/task/executepolling/00000000-0000-0000-0000-000000000000/00000/status
# If 202 Accepted: Repeat at regular intervals (30 seconds)
# If 200 OK: Read job status and continue

RAW HTTP

Copy 
POST /task/executepolling/00000000-0000-0000-0000-000000000000 HTTP/1.1
Host: iimport.cloud.csiinc.com
User-Agent: example-documentation/1.0
Content-Length: 0
202 Accepted
Location: /task/executepolling/00000000-0000-0000-0000-000000000000/00000/status
Retry-After: 30
Content-Type: application/json
{ ... }
GET /task/executepolling/00000000-0000-0000-0000-000000000000/00000/status HTTP/1.1
Host: iimport.cloud.csiinc.com
User-Agent: example-documentation/1.0
Content-Length: 0
202 Accepted
Location: /task/executepolling/00000000-0000-0000-0000-000000000000/00000/status
Retry-After: 30
Content-Type: application/json
{ ... }
GET /task/executepolling/00000000-0000-0000-0000-000000000000/00000/status HTTP/1.1
Host: iimport.cloud.csiinc.com
User-Agent: example-documentation/1.0
Content-Length: 0
200 OK
Content-Type: application/json
{ ... }

Passing IQA Query Parameters with Webhooks

It is possible to pass IQA parameters (prompts marked "Optional" or "Required" in iMIS) into a webhook request (standard or polling) and have those parameters apply to the IQA dynamically at runtime.

To view the webhook body template and the list of available parameters, click the information icon next to the task Name and expand the Query Parameters Overload on POST Request section. A preview window will display a JSON object template that can be used to pass parameters into the webhook:

Note: This JSON object should be included in your initial webhook POST body. 

IQA Query Parameter Key Names

The names of the parameters are derived from the column name from the business object (or source IQA) of the corresponding filter row in the source IQA. 

For filter lines using CsContact.FirstName, CsContact.LastName, and CsContact.Email, the corresponding JSON object for query parameter keys would be structured as follows:

Copy 
{
  "QueryParameters": {
    "FirstName": "",
    "LastName": "", 
    "Email": "", 
  }
}

Note: Passing in a null or empty string will cause iDMS to use the default parameter provided in the iDMS interface when the task was set up, or, the default parameter in the IQA if the iDMS task also does not have a value.

Important! It is not currently possible to have two filter rows in an IQA that share the same column name. For example, if you add CsContact1 and CsContact2 (linked via the Company ID relationship), it would not be possible to provide parameter values for both the parent company "ImisId" and individual child "ImisId" filters at the same time, since the column name is the same.