| Layer | Campaign Manager |
| Direction | To CallGem |
| Type of Service | CM |
| Interface ID | DE |
| Message Purpose | This message is sent to the CampaignManager layer requesting it insert a new record into the database |
| Example | CM:DE:IR\TDdefault\CNSales\TX1234\DTxml column data |
| Explanation | The client is requesting to add a new database record to the 'Sales' campaign on the 'default' tenant. The record will contain data in the DT param and will be added for immediate dialling |
| Notes |
The Insert Record message adds the record to the database, marks the record as in cache, and then places the record at the head of the cache, which means it will be pulled into the dialer on the next request for a number to dial. This will, on most running campaigns, result in the number being dialed in a 1 to 5 minute time window. However, this is not guaranteed. The Insert Record mechanism ensures that newly-added records are dialed as soon as practically possible without interrupting the flow of other scheduled work, but for the reasons above there is not a 100% guarantee that the record will be dialed in a particular time period. If many of the agents in the dialer are processing callbacks, the rate at which new numbers are requested by the dialer will be slower. Also, in the case of a bulk insert of e.g. 200 records, those 200 records will be placed at the head of the cache. If the dialer does not work through the 200 records in the next 15 minutes (because of lack of load), then again there is no guarantee. It is possible to guarantee a dial in short order by writing a record directly to the database as a non-agent-specific callback. To do this, insert a row with the retry time column set to the UTC time at which to dial, and the retry agent column set to the literal string _ZZCallback_. If there are no agents available on the campaign (because they are all busy processing callbacks or long-duration calls), the callback will wait for an agent to become available. If no agents are logged in, the callback will be returned undialed and then made subject to retry processing for callbacks. See also SDMP Message Protocol |
| Introduced | 10.6.255 |
| Parameters | ||||||
|---|---|---|---|---|---|---|
| Code | Name | Type | Mandatory? | Min Val | Max Val | Description |
| CN | CampaignName | string | true |
1 | 80 | From V10.6.263 - Identifies the target campaign table by name. |
| CY | CampaignIdentifier | int | true (See Description) | 0 | 9999 | From - V10.7.830 - A unique integer ID for the target campaign table, which can be extracted from the Status Broadcast message. Either the CN or CY parameter must be passed. |
| DT | Data |
|
true | 1 | 128000 | The DT parameter, if specified in the AddCampaign method, should contain an XML string. |
| TD | TenantDescriptor | string | true | 1 | 80 |
Mandatory when operating in
Multi-Tenancy. Otherwise it must not be used.
This parameter is alphanumeric and identifies to which tenant this message applies. Typically contains a company name. |
| TX | TransactionIdentifier | string | true | 1 | 87 | Used by CallGem to identify to which request this message is responding. Must be unique across all requests. |