Skip to main content
Skip table of contents

mPulse functional guide

This page provides information about the capabilities of mPulse within Redpoint Interaction (RPI), how sending messages/synchronizing state data works, and links to other resources.

Key capabilities

The mPulse SMS connector providers the following key capabilities:

  • Channel Configuration

  • The ability to send SMS messages via an Interaction using an Offer Activity and/or Queue Listener

  • Receiving state/disposition data via the Channel Synchronization Task

  • Using state/disposition data as inputs to additional workflows and downstream activities

Unique features

Compared to the other SMS connectors that RPI supports, the mPulse connector supports the following features:

  • Processing of state/disposition data via their webhook functionality

  • Ideal platform to use for Queue Listeners, as they support timely delivery of SMS messages

  • Various channel configuration options to optimize performance for outbound and inbound processing

Process flow

The following flow chart shows how the mPulse channel works within both outbound fulfillment and inbound state synchronization.

Outbound processing

Inbound processing

Outbound fulfillment

The mPulse connector performs the following steps when it is used as part of an outbound Offer Activity:

Step #

Step Description

APIs / SQL

1

Initiate a connectivity test to validate the mPulse service is accessible. The connectivity test will fail if the response code does not return a 200.

Method: PUT

Endpoint: https://ms-api.mpulsemobile.com/accounts/<account_id>/members

Headers: 

  • Authorization: Basic password_in_base64_format

  • X-Ms-Source: api

  • X-Ms-Format: json

  • X-Ms-Ignore-Error-For-Existing-Members: true

  • X-Ms-Update: included_fields_only

  • X-Ms-Audience-Update: upsert

  • X-Ms-Force-Subscribe-Member: true

Request Body: 

JSON
{
  "body": {
    "member": [
        {
            "mobilephone": "17817250250"
        }
    ],
    "listid": "9966"
  }
}

Response Body (Example):

JSON
{
  "body": {
    "results": {
      "success": 1,
      "failure": 0
    },
    "members": [
      {
        "member": {
          "id": {
            "mobilephone": "17817250250",
            "memberid": 105096612
          },
          "result": "success",
          "profile": {
            "RMENABLED": false,
            "MOBILEPHONE": "17817250250",
            "DATEADDED": "2023-03-05 19:34 PST",
            "MEMBERID": 105096612
          },
          "subscriptions": {
            "sms": {
              "status": "ACTIVE"
            }
          }
        }
      }
    ]
  }
}

2

If the connectivity fails, it will retry up to 10 attempts with an interval of every 1 minute.

N/A

3

If the channel is configured to auto-suppress unsubscribes, RPI will query the suppression SMS table to identify and suppress any matching phone numbers before generating batch for member records. 

N/A

4

Render personalized content for each member using the Razor template. Each personalized content is written to specific member list batch and event upload batch. The number of records of a batch varies depending on the values configured in Max. list upload batch size and Max. event upload batch size channel configuration settings.

N/A

5

Member records are uploaded into mPulse in batch. If Enable asynchronous list upload is set to true, member records of specific batch are uploaded asynchronously. The number of records per batch generated are based on the value configured in Max. list upload batch size channel setting. In this case, the recommended value for asynchronous upload is 2000, otherwise 50 for synchronous upload. Batches are processed concurrently based on the value configured in Max. send threshold where its default value is 10.

Phone Number Formatting:

Phone numbers must be sanitized manually before utilizing them in any RPI SMS campaign executions using mPulse connector. The phone number must be in the following format:

<Country Code><Phone Number>

e.g., 14107036494

Country Code must not be preceded by + symbol as mPulse is omitting this during callback service calls.

If the + symbol is included in the phone numbers during SMS campaign send, the corresponding mPulse events will not be ingested into offer history state table.

Method: PUT

Endpoint: https://ms-api.mpulsemobile.com/accounts/<account_id>/members

Headers (Asynchronous Member List Upload): 

  • Authorization: Basic password_in_base64_format

  • X-Ms-Source: api

  • X-Ms-Format: json

  • X-Ms-Ignore-Error-For-Existing-Members: true

  • X-Ms-Update: included_fields_only

  • X-Ms-Audience-Update: upsert

  • X-Ms-Force-Subscribe-Member: true

  • X-Ms-Async: true

Request Body (example):

JSON
{
  "body": {
    "member": [
      {
        "mobilephone": "09172420196",
        "rpcontactid": "14955449",
        "custid": "7185035",
        "emailaddr": "test.6d95a6e63c@test.com"
      },
      {
        "mobilephone": "09173961480",
        "rpcontactid": "14955450",
        "custid": "7357928",
        "emailaddr": "test.87282fcf5a@test.com"
      }
    ],
    "listid": "9966"
  }
}

Response Body (Example):

JSON
{
  "body": {
    "request_info": {
      "request_id": "ccd95c31-f9d0-4e21-aca1-6deb9753c3e4"
    }
  }
}

Headers (Synchronous Member List Upload): 

  • Authorization: Basic password_in_base64_format

  • X-Ms-Source: api

  • X-Ms-Format: json

  • X-Ms-Ignore-Error-For-Existing-Members: true

  • X-Ms-Update: included_fields_only

  • X-Ms-Audience-Update: upsert

  • X-Ms-Force-Subscribe-Member: true

Request Body (example):

JSON
{
  "body": {
    "member": [
      {
        "mobilephone": "09172420196",
        "rpcontactid": "14955449",
        "custid": "7185035",
        "emailaddr": "test.6d95a6e63c@test.com"
      },
      {
        "mobilephone": "09173961480",
        "rpcontactid": "14955450",
        "custid": "7357928",
        "emailaddr": "test.87282fcf5a@test.com"
      }
    ],
    "listid": "9966"
  }
}

Response Body (Example):

JSON
{
  "body": {
    "results": {
      "success": 2,
      "failure": 0
    },
    "members": [
      {
        "member": {
          "id": {
            "mobilephone": "09172420196",
            "memberid": 115098812
          },
          "result": "success",
          "profile": {
            "RMENABLED": false,
            "MOBILEPHONE": "09172420196",
            "DATEADDED": "2023-03-05 19:34 PST",
            "MEMBERID": 115098812,
            "RPCONTACTID": "14955449",
            "CUSTID": "7185035",
            "EMAILADDR": "test.6d95a6e63c@test.com"
          },
          "subscriptions": {
            "sms": {
              "status": "ACTIVE"
            }
          }
        }
      },
      {
        "member": {
          "id": {
            "mobilephone": "09173961480",
            "memberid": 126097812
          },
          "result": "success",
          "profile": {
            "RMENABLED": false,
            "MOBILEPHONE": "09173961480",
            "DATEADDED": "2023-03-05 19:34 PST",
            "MEMBERID": 126097812,
            "RPCONTACTID": "14955450",
            "CUSTID": "7357928",
            "EMAILADDR": "test.87282fcf5a@test.com"
          },
          "subscriptions": {
            "sms": {
              "status": "ACTIVE"
            }
          }
        }
      }
    ]
  }
}

6

One or more member SMS event batches are sent into the default queue provider using the queue path value configured in Event upload content queue path channel setting. For each execution, a new queue path is created from the default queue provider if it is does not exist yet. The created queue path has the following format: Event upload content queue path<CHID>.

Regardless of whether the Enable asynchronous event upload option is configured or not, SMS event batch will always be sent to the queue. If Enable asynchronous event upload is set true, the recommend value for Max. event upload batch size is 2000, otherwise 50. Batches are processed concurrently based on the value configured in Max. send threshold where its default value is 10.

N/A

7

After uploading the specific member list batch asynchronously, mPulse service will be returning the result of the import job. The import job contains a JobID which will be using by RPI to monitor the process of the import. However, if all member list batches uploaded synchronously have been completed, the execution will proceed on reading the SMS events from the queue in preparation for sending them into mPulse service.

N/A

8

If member list batch uploaded asynchronously, RPI will be creating a database table called RPI_MPulseMemberUpload on client's main data warehouse. The import job ID, channel execution ID, batch ID, and the date and time of execution will be saved into this table. These details will be used to monitor the import process of specific member list batch uploaded asynchronously.

SQL Query (Example):

SQL
INSERT INTO [dbo].[RPI_MPulseMemberUpload] (
    [Batch],
    [JobId],
    [ChannelExecutionID],
    [UploadDateTime]
)
VALUES (
    '1',
    '9ec19bd0-7835-4d7f-86e1-855d8b692bf0',
    79217,
    '2023-07-31 16:00:35.393'
);

9

Once all member list batches have been uploaded asynchronously, RPI will be monitoring the import jobs recorded in RPI_MPulseMemberUpload database table. While in monitoring state, you will able to see log message e.g., "Member list import status: 0 out of 3 batch(es) uploaded. Will retry in 5 seconds...".

The monitoring will continue every 5 seconds until it reaches the waiting time configured in Member list import timeout channel setting. During monitoring of the import jobs, only single main database connection is open for every database query being executed.

N/A

10

The import job status for each member list batch is sourced out from the database table called RPI_MPulseMemberImportStatus on client's main data warehouse. When the record count from RPI_MPulseMemberUpload and RPI_MPulseMemberImportStatus database tables are equal for specific execution, RPI will log the number of records processed with total successful and failed.

SQL Query (Example):

SQL
SELECT COUNT(*)
FROM [dbo].[RPI_MPulseMemberUpload] AS a24 WITH (NOLOCK)
WHERE EXISTS (
    SELECT a25.[JobId]
    FROM [dbo].[RPI_MPulseMemberUpload] AS a25
    INNER JOIN [dbo].[RPI_MPulseMemberImportStatus] AS a26 ON a25.[JobId] = a26.[JobId]
    WHERE a24.[JobId] = a25.[JobId]
      AND a25.[JobId] = a26.[JobId]
)
AND a24.[ChannelExecutionID] = 79218;

11

If there is no import status yet available for specific member list, and the waiting time has expired, the monitoring for import jobs will be terminated, and the Interaction workflow activity execution is set to failed state with the appropriate log messages.


N/A

12

All SMS event batches were stored in the queue path of the default queue provider will be fetched in preparation for sending these payloads into mPulse provider. The process of sending these payloads done concurrently based on the value configured in Max. send threshold. The sending process will continue until there are no payloads available in the queue.

In the event of error however, a new queue path will be created with name in the following format: [Event upload content queue path]<CHID><# of Attempt>Failed. The failed SMS event batch will be sent into this queue. When one or more SMS event batches failed, the Interaction workflow is set to failed state with the appropriate log messages. If the user re-plays the workflow activity, will attempt to resend the payload of these failed batches to mPulse.

Method: POST

Endpoint: https://ms-api.mpulsemobile.com/account/<account_id>/uploadEvent

Headers (Asynchronous SMS event upload): 

  • Authorization: Basic password_in_base64_format

  • X-Ms-Source: api

  • X-Ms-Format: json

  • X-Ms-API-Version: 2.0

  • X-Ms-Async: true

Request Body (example):

CODE
{
    "body": {
        "events": {
            "name": "RPI",
            "event": [
                {
                    "scheduled_on": "+00:00",
                    "timezone": "US/Pacific",
                    "evaluation_scope": "no_rule",
                    "mobilephone": "09171535650",
                    "correlationid": "14965474|80218|fab7603d-51f6-4cf3-b1a1-758c9a325cf3",
                    "content": "7150886 | test.cb2f6834c0@test.com | 09171535650"
                },
                {
                    "scheduled_on": "+00:00",
                    "timezone": "US/Pacific",
                    "evaluation_scope": "no_rule",
                    "mobilephone": "09176257615",
                    "correlationid": "14965475|80218|fab7603d-51f6-4cf3-b1a1-758c9a325cf3",
                    "content": "7541036 | test.9e8ef7a0b3@test.com | 09176257615"
                }
            ]
        },
        "listid": "9966"
    }
}

Response Body (example):

JSON
{
    "body": {
        "result": {
            "status": "success",
            "message": "UploadEventisbeingprocessedinbackground.StatusofprocessingisavailableongivenURL.",
            "url": "https://ms-api.mpulsemobile.com/account/1485/uploadEventStatus?requestId=14855e62795348de49bb9b6096daeffff38b"
        }
    }
}

13

Every successful SMS event batch being sent to mPulse provider is monitored by checking the upload status using the value of request_id returned by UploadEventStatus API endpoint.

Method: GET

Endpoint: https://ms-api.mpulsemobile.com/account/<account_id>/uploadEventStatus?requestId=<request id provided by mPulse>

Headers: 

  • Authorization: Basic password_in_base64_format

  • X-Ms-Source: api

  • X-Ms-Format: json

  • X-Ms-API-Version: 2.0

Response Body (example):

JSON
{
    "body": {
        "results": {
            "processed_event_instances": "1",
            "scheduled_messages": "0",
            "errors": "1",
            "details": {
                "listid": "9966",
                "events": {
                    "event_definition_id": "4656",
                    "event_definition_name": "RPI",
                    "event": {
                        "event_instance_request_index": "0",
                        "correlationid": "14965478|80218|fab7603d-51f6-4cf3-b1a1-758c9a325cf3",
                        "memberid": "None",
                        "scheduled_messages": null,
                        "errors": {
                            "error": {
                                "error_code": "ERR-EVENT-008",
                                "error_message": "The member in the event instance is either null or is not a valid member."
                            }
                        }
                    }
                }
            }
        }
    }
}

14

If the upload status is complete for specific SMS event batch, mPulse campaign is triggered per the event configured. Otherwise, it will wait for 60 seconds before the UploadEventStatus API endpoint called again.

N/A

15

If SMS event batches are successfully sent, the created queue path for specific execution will be cleanup. The Interaction log is updated with the total number of batches that were sent and failed.

N/A

The Enable asynchronous list upload and Enable asynchronous event upload channel settings do not apply in the context of Queue Listener executions. Members and SMS Events are directly sent to mPulse without performing any extra monitoring on each API request.

The following are the database tables created during the outbound execution:

Table Name

Description

RPI_MPulseMemberUpload

Contains details such as Job ID of the member list batch uploaded asynchronously.

RPI_MPulseSendLookup

Contains details of SMS event batch uploaded.

State data synchronization

Inbound process

Step #

Step Description

APIs / SQL

1

mPulse SMS provider will be sending events via Redpoint Interaction callback service. Typically, mPulse will invoke the callback service URL configured. The URL is in the following format:

https://<HOST NAME OR IP ADDRESS>/mPulseCallbackServiceWebAPI/PostEvents/<Client ID>

The <Client ID> parameter is a specific RPI client ID.

The events posted via callback service API will be sent to the queue path configured in CallbackServiceQueuePath system configuration. In case of any failure occurred in posting the events sent by mPulse, these events will be written to the directory configured in mPulseSmsMetricsFolderPath cluster setting. The files in this directory will not be processed but for the purpose of troubleshooting.

N/A

2

The Callback service processor system task reads and process the events available in the queue configured in CallbackServiceQueuePath setting. Processing of events will continue until there are no events available in the queue.

N/A

3

If client's main data warehouse is running either Snowflake DB or AWS Redshift DB, the recommendation is to utilize S3 bucket to bulk-load the records from S3 to temp table on the database.

N/A

4

To enable bulk-load using S3 bucket, enable the following RPI system configuration options:
AWSPerformCOPYFromS3 = true
AWSSourceS3BucketName = <ECP Name>\<Bucket Name>

N/A

5

When the Callback service processor system task process the events from the queue, each mPulse event is identified as MO (Mobile Originated), SUB (Subscribe), UNSUB (Unsubscribe), and BULKUPSERT (Member List Upload Asynchronous Results).

Example of MO (Mobile Originated):

JSON
{
    "body": {
        "short_code": "12073591104",
        "mobile_phone_number": "18332057841",
        "content": "STOP",
        "carrier": "ClearSky",
        "received_datetime": "2022-12-16 12:07:46.334932 PST",
        "mo_id": 42376892,
        "list_id": 10317,
        "campaign_id": 59338,
        "message_id": 234952,
        "action": "MO",
        "correlation_id": "52",
        "client_member_id": null,
        "member_id": 98180015
    }
}

Example of SUB (Subscribe):

JSON
{
    "body": {
        "mobile_phone_number": "18332057841",
        "list_id": 10317,
        "member_id": 98180015,
        "request_datetime": "2022-12-16 12:11:03.082088 PST",
        "api_username": null,
        "action": "SUB",
        "client_member_id": null
    }
}

Example of UNSUB (Unsubscribe):

JSON
{
    "body": {
        "mobile_phone_number": "18332057841",
        "list_id": 10317,
        "member_id": 98180015,
        "request_datetime": "2022-12-16 12:07:46.430671 PST",
        "api_username": null,
        "action": "UNSUB",
        "client_member_id": null
    }
}

Example of BULKUPSERT (Member List Upload Asynchronous Results):

CODE
{
    "body": {
        "request_id": "5152d1c3-4e8b-46b6-a2d5-cc1a31da2407",
        "http_status": 400,
        "response": {
            "body": {
                "results": {
                    "success": 2,
                    "failure": 2
                },
                "members": [
                    {
                        "member": {
                            "id": {
                                "mobilephone": "16173957817"
                            },
                            "result": "failure",
                            "member_errors": [
                                {
                                    "member_error": {
                                        "code": "MS-ERR-003",
                                        "message": "Invalid parameter value",
                                        "detail": {
                                            "parameter": "MOBILEPHONE",
                                            "value": "16173957817",
                                            "reason": "UNSUPPORTED_CARRIER"
                                        }
                                    }
                                }
                            ]
                        }
                    },
                    {
                        "member": {
                            "id": {
                                "mobilephone": "17814844462"
                            },
                            "result": "failure",
                            "member_errors": [
                                {
                                    "member_error": {
                                        "code": "MS-ERR-003",
                                        "message": "Invalid parameter value",
                                        "detail": {
                                            "parameter": "MOBILEPHONE",
                                            "value": "17814844462",
                                            "reason": "UNSUPPORTED_CARRIER"
                                        }
                                    }
                                }
                            ]
                        }
                    },
                    {
                        "member": {
                            "id": {
                                "mobilephone": "18332057841",
                                "memberid": 109749142
                            },
                            "result": "success",
                            "profile": {
                                "DATEADDED": "2023-05-22 11:23 PDT",
                                "STATE": "Ohio",
                                "RMENABLED": false,
                                "MOBILEPHONE": "18332057841",
                                "GENDER": "Male",
                                "FIRSTNAME": "QUENNA",
                                "LASTNAME": "ROBIDA",
                                "MEMBERID": 109749142
                            },
                            "subscriptions": {
                                "sms": {
                                    "status": "ACTIVE"
                                }
                            }
                        }
                    },
                    {
                        "member": {
                            "id": {
                                "mobilephone": "18333376198",
                                "memberid": 109749143
                            },
                            "result": "success",
                            "profile": {
                                "DATEADDED": "2023-05-22 11:23 PDT",
                                "STATE": "Missouri",
                                "RMENABLED": false,
                                "MOBILEPHONE": "18333376198",
                                "GENDER": "Male",
                                "FIRSTNAME": "TOLULOPE",
                                "LASTNAME": "AASBY",
                                "MEMBERID": 109749143
                            },
                            "subscriptions": {
                                "sms": {
                                    "status": "ACTIVE"
                                }
                            }
                        }
                    }
                ]
            }
        },
        "action": "BULKUPSERT",
        "client_member_id": null,
        "member_id": 103694736
    }
}

6

If the response type is MO, the details of the MO event will be ingested into RPI_MPulseEvents table.

If the response type is SUB or UNSUB, the details will be ingested into RPI_MPulseSubscription table.

Finally, if the response type is BULKUPSERT, the details will be ingested into the following database tables: RPI_MPulseMemberImportStatusRPI_MPulseAsynchronousResult, and RPI_MPulseAsynchronousFailure.

N/A

7

The mPulse channel synchronization system task process all state data from RPI_MPulseEvents table. Responses with STOP, STOP ALL, HELP, and START are loaded into Offer History States table. Any other response is loaded as Mobile Originated.
STOP ALL records are loaded to the Suppression_SMS table or custom suppression table if configured.


SQL Query (Example):


SQL
SELECT
    [MessageId]          = a1.[MessageId],
    [ListId]             = a1.[ListId],
    [Content]            = a1.[Content],
    [Action]             = a1.[Action],
    [ReceivedDatetime]   = a1.[ReceivedDatetime],
    [ChannelExecutionID] = a1.[ChannelExecutionID],
    [ChannelId]          = a1.[ChannelId],
    [MobilePhoneNumber]  = a1.[MobilePhoneNumber],
    [EntryDate]          = a1.[EntryDate]
FROM
    [dbo].[RPI_MPulseEvents] a1
WHERE
    (
        a1.[ChannelExecutionID] = <CHID>
        AND a1.[ChannelId]       = '<Channel ID>'
        AND a1.[EntryDate]       >= '<Start Date>'
    )

The following are the database tables created during the inbound processing:

Table Name

Description

RPI_MPulseEvents

Contains MO event details e.g., Stop, Stop All, Help, and Start

RPI_MPulseMemberImportStatus

Contains the Member list import details such as the Job ID. Each Job ID corresponds to specific member list batch uploaded asynchronously. Records are source out from the callback service BULKUPSERT response type.

RPI_MPulseAsynchronousResult

Contains the Member list import details that were imported successfully. Records are source out from the callback service BULKUPSERT response type.

RPI_MPulseAsynchronousFailure

Contains the Member list import details that were failed during mPulse import process. Records are source out from the callback service BULKUPSERT response type.

RPI channel configuration

The following channel-specific fields are shown for the mPulse SMS channel:

Configuration Field

Details

API Service URL

Mandatory text property represents the API service URL used to connect to the mPulse service. It defaults to the value https://ms-api.mpulsemobile.com/. It can be a maximum of 500 characters in length.

Username

Mandatory text property allows you specify a username to be used to connect to the mPulse service. It accepts a maximum of 100 characters.

Password

Mandatory password-masked text field allows you specify a password to accompany the supplied username. It accepts a maximum of 100 characters.

Account Id

Mandatory text property represents the account ID that will be used to connect to the mPulse service. This value can be found in the portal or provided by mPulse. It accepts a maximum of 100 characters.  

Audience list Id

Combo-box field represents an Audience list ID in the context of which all uploaded contacts will be grouped together. Specification of an audience list ID is mandatory. It is accompanied by an Add button, which allows you to specify one or more audience list IDs. Each can be a maximum of 100 characters in length. 

Refer to Step 2 in Section 2 of the "mPulse Configuration" section for information on identifying this value.

Event name

Mandatory text property represents the event name that will be used to send mPulse SMS messages. It accepts a maximum of 100 characters.   

Refer to Step 2 in Section 3 of the "mPulse Configuration" section for information, which should reflect the same configured name. 

Content attribute name

Mandatory text property represents the custom attribute name that will be used to render SMS content for each subscriber. It accepts a maximum of 50 characters.

Refer to Step 3 in Section 3 of the "mPulse Configuration" section for information, which should reflect the same configured name. 

Mobile phone

Mandatory text property represents the phone number that will be used to test connectivity of the mPulse service. It accepts a maximum of 100 characters.   

Any valid phone number can be used within this property.  

Max. list upload batch size

Numeric property represents the maximum number of recipients sent at a time to mPulse. It defaults to 50 and accepts a range of values from 1 to 2000.

Max. event upload batch size

Numeric property represents the maximum number of SMS events sent at a time to mPulse. It defaults to 2000 and accepts a range of values from 1 to 2000.

Lowering this value will result in longer campaign execution times. 

Enable asynchronous list upload

If this option is set, member list batch will be uploaded asynchronously. 

For larger send, it is recommended to set this option.  

Enable asynchronous event upload

If this option is set, SMS event batch will be uploaded asynchronously.

For larger send, it is recommended to set this option.

Max send threshold

Numeric property represents the maximum number of concurrent send operations that can be executed for a batch of email campaigns. It defaults to 10 and accepts a range of values from 1 to 10.

Callback Service URL

The public-facing URL that mPulse will use to post the response and subscription events.  

Event upload content queue path

Mandatory text property allows you to configure a queue path of the default queue provider where SMS event batches are sent before they will be sending to mPulse. It accepts a maximum of 1000 characters.

Member list import timeout

Numeric property represents the total waiting time (in minutes) of the member list import to complete. It defaults to 10 and accepts a range of values from 60 to 99999.

Callback service installation configuration

Installation

To install the RPI mPulse Web API Callback Service:

  1. Copy the entire Deployment Files\Plugins Services\mPulseCallbackServiceWebAPI folder into the root of the IIS web site where the mPulse Web API callback service will be hosted.

  2. In the App_Config folder, copy the ConnectionStrings.Example.config file and paste it in the same location. Rename the file to ConnectionStrings.config.

  3. In the ConnectionStrings.config file, modify the two entries within the <connectionString> tags to point to the database server where the core RPI operational database is housed by replacing the localhost string in the entries below with the name of the operational database server. If the RPI operational database is on the same machine as the RPI application server, then this does not need to be changed:

XML
    <add name="LoggingDatabase"
         connectionString="Data Source=.;Initial Catalog=Pulse_Logging;Integrated Security=True;Connect Timeout=90;ConnectRetryCount=12;ConnectRetryInterval=10"
         providerName="System.Data.SqlClient" />
    <add name="OperationalDatabase"
         connectionString="Data Source=.;Initial Catalog=Pulse;Integrated Security=True;Connect Timeout=90;ConnectRetryCount=12;ConnectRetryInterval=10"
         providerName="System.Data.SqlClient" />

In IIS Manager:

  1. Expand the website you created for the mPulse callback service.

  2. Right-click on the mPulseCallbackServiceWebAPI folder and choose Convert to Application.

  3. Set the Application Pool to the same application pool that RPI runs under (RPIAppPool) or, if hosted on a different server, make sure the application pool runs under a security context that has access to the RPI Operational database referenced in the step above.

  4. You can test that your service is running correctly by right-clicking on the mPulseCallbackServiceWebAPI application in IIS and choosing Browse. If the service is running, you will see NuGet Dependencies content.

Important:

Once the callback service has been configured, submit a request into mPulse support and ask them to configure the callback URL with the following callback types:

  1. Asynchronous Callback (this is used for the member upload)

  2. SMS Subscription (these capture members that are new to the list ID configured in the channel)

  3. SMS Unsubscription (these capture members who opt-out)

  4. Mobile Originated (MO) callback (these capture the responses)

The callback URL is formatted as follows:

http://<FQDM or IP>:<port (optional)>/PostEvents/<rpi_client_id>

Ports:

When using Azure Service Bus as the queue, configure the firewall rule to allow outbound traffic to ports 443, 5671, and 5672.

Upgrade

To upgrade the mPulse callback service at an existing RPI installation, please follow these steps:

  1. Back up the mPulse Web API callback service App_Config\ConnectionStrings.config file and appsettings.json file.

  2. Stop the mPulse Web API callback service in IIS Manager.

  3. Copy the contents of DeploymentFiles\Plugin Services\mPulseCallbackServiceWebAPI into the mPulse Web API callback service website’s root folder.

  4. Start the mPulseCallbackServiceWebAPI application from IIS manager.

mPulse configuration

The following section provides the pre-requisite steps for configuring mPulse to work with RPI.

1: Log into mPulse portal

Step #

Description

1

In a web browser, navigate to https://auth.mpulsemobile.com/ and click Communication Console.

2

Specify a username and password and click NEXT.

2: Create audience

Step #

Description

1

Navigate to Audience > Lists and click the Create a List button:

2

Enter a name and description for the List and click the Enable SMS channel option, which will expose additional options:

  1. Select the shortcode to be used for the messages.

  2. Enter an SMS Keyword, specified by mPulse.

  3. Click the Create button to save.

Once the List has been created, note the LIST ID associated with this list, as that will be used in the configuration of the channel in RPI, which is found in the URL of the Audience:
https://apps.mpulsemobile.com/audience/lists/10317/members

3: Create event

Step #

Description

1

Navigate to My Settings > Event Definitions and click the New Event button:

2

Specify a Name and click on Add Attribute under the Attributes section:

3

In the Attribute Name textbox, enter the value content with a data type of String, and then click the Create button:

4: Create campaign

Step #

Description

1

Navigate to the Communication tab and click the New Campaign button:

2

Enter a name, choose the audience (created in the earlier steps), and choose SMS. Once complete, click the Save & Next button:

3

In the content section Type Your SMS Here: of the message, enter the following: ##EVENT.CONTENT##

4

Scroll to the bottom and click the Edit Trigger icon, and then configure the following:

  1. Expand Trigger on member engagement and select Custom Event tab.

  2. On occurrence of event = Redpoint Event (or name of the event created in the prior step).

  3. Send Message = As often as triggered.

  4. Click the Add Trigger button.

5

Click the NEXT button.

6

Choose Scheduled Immediately with No End Date and click the Launch Campaign button.

Performance testing

Performance test environment specifications

  • 2 VMs with 8 cores and 32GB of memory to be used for RPI (2 nodes)

  • 1 VM with 4 cores and 16GB or memory to be used for RPDM

  • 1 VM with 2 cores and 8GB of memory to be used for Realtime (supporting queue listener sends)

  • Azure SQLDB elastic pool instance for the marketing and ops database

  • Snowflake Datawarehouse (v7.28.0)

    • X-Small warehouse with single cluster

  • Snowflake ODBC driver (3.00.02.00)

  • Azure Service Bus Queue Provider

RPI application settings

Volume test scenarios

Scenario

Details

SMS Batch Sends

  • 1,000 contacts

  • 2,000 contacts

  • 5,000 contacts

  • 10,000 contacts

Concurrent Sends

  • 10 Campaigns at 500 each run concurrently

  • 10 Campaigns at 1K each run concurrently

Queue Listener Sends

  • 500 requests with random time of 0 to 1 second between requests

  • 1000 requests with random time of 0 to 1 second between requests

  • 2500 requests with random time of 0 to 1 second between requests

  • 5000 requests with random time of 0 to 1 second between requests

mPulse can only send 1 file/record at a time.

Inbound

Inbound records processing via callback service processor

Functional testing results

All functional tests have been passed, and no known issues exist.

Volume test results

Batch sends

Batch Sends

Upload Contacts Time (2000 batch size) - RPI

Member List Import Status
(Total waiting time until initial batch result received) - mPulse

Member list upload time
(Total waiting time until all batch imported) - mPulse

SMS Event Upload Time
(2000 batch size) - RPI

Total Workflow Execution

1000

3 seconds

5 minutes & 28 seconds

5 minutes & 33 seconds

13 seconds

6 minutes & 48 seconds

2000

3 seconds

10 minutes & 50 seconds

10 minutes & 55 seconds

20 seconds

12 minutes & 11 seconds

5000

7 seconds

18 minutes & 12 seconds

28 minutes & 47 seconds

29 seconds

30 minutes & 33 seconds

10000

9 seconds

55 minutes & 52 seconds

58 minutes & 4 seconds

27 seconds

59 minutes & 46 seconds

Concurrent sends

Concurrent workflow running (audience size) (batch size)

Earliest start time

Longest end time

Total offer execution

10 (500) (2000)

08:44:14

09:13:12

28 minutes & 58 seconds

10 (1000) (2000)

09:28:29

10:28:24

59 minutes & 55 seconds

Queue listener sends

Concurrent Sends

Number Received

500

500

1000

1000

2500

2500

5000

5000

The total execution time for a single queue listener request is, on average, 11 seconds (from initial QL request to send request).

Inbound

Events in Queue

Callback Service Processor Execution Time (CallbackServiceProcessorNumReaders set to 1)

Callback Service Processor Execution Time (CallbackServiceProcessorNumReaders set to 10)

Channel Synchronization Execution Time

50K

5 minutes & 20 seconds

3 minutes & 11 seconds

1 minutes & 33 seconds

100K

9 minutes & 21 seconds

5 minutes

2 minutes & 6 seconds

100K

46 minutes & 24 seconds

22 minutes & 16 seconds

10 minutes & 12 seconds

1M

1 hour 34 minutes & 10 seconds

47 minutes & 56 seconds

25 minutes & 23 seconds

Limitations

Limitation #

Limitation Detail

1

Up to 2K members can be uploaded per batch when asynchronous list upload is enabled.   

Up to 50 members can be uploaded per batch when asynchronous list upload is disabled.   

Each API call to the Members endpoint, on average, completed in less than a second.

2

Up to 2K SMS Events can be uploaded per batch when asynchronous list upload is enabled.   

Up to 50 SMS Events can be uploaded per batch when asynchronous list upload is disabled.   

Each API call to the Upload Event endpoint, on average, completed in less than a second.

3

When uploading members to a list asynchronously, each batch (up to 2K members) will initiate a job request in mPulse. Once the job is complete, an async callback is posted to the callback URL configured in the channel and the callback system. When all batches have been processed and posted to the callback URL, RPI will initiate the Event send requests. It was observed that uploading new members to a list will take approximately 45-60 minutes to upsert a list of 10,000 recipients. If the members already exist in the list, the upsert of 10,000 recipients will complete within 1 minute.     

4

This integration does not support two-way messaging via the mPulse Dialogue capabilities, as there are currently no APIs to interact with that product.   

Logging

Below is an example of the Interaction log for an offer using the mPulse channel:

Log

Log Entry Descriptions

2023/08/15 16:30:44 Action: mPulse Channel Activity: Queue deletion completed

All SMS events queues have been cleaned up successfully.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Event upload queue 'rpieventuploadxxx183271Failed1' deleted:- Success

Indicates that deletion of the SMS events queue is successful.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Attempt to cleanup Event upload queue:- rpieventuploadxxx183271Failed1

Indicates an attempt to delete the SMS events queue.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Event upload results:
Total event upload with errors:- 0
Total batch processed:- 3
Total batch failed:- 0

The statistical report details of SMS events upload.

  • Total event upload with errors. The total number of SMS events uploaded with errors.

  • Total batch processed. The total number of SMS events batches have been processed.

  • Total batch failed. The total number of SMS events batches have been processed, and it failed.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Event upload queue 'rpieventuploadxxx183271' deleted:- Success

Indicates that deletion the SMS events queue is successful.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Attempt to cleanup Event upload queue:- rpieventuploadxxx183271

Indicates an attempt to delete the SMS events queue.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Event Upload, batch #1 with 2 record(s):- Success

Indicates that a batch of SMS events sent via API call is successful.

2023/08/15 16:30:44 Action: mPulse Channel Activity: Fetching next event upload batch from queue 'rpieventuploadxxx183271':- Success

Indicates an attempt to retrieve the next batch of SMS events from the queue.

2023/08/15 16:30:42 Action: mPulse Channel Activity: Sending event upload batch #1...

Indicates an attempt to send a batch of SMS events via API call.

2023/08/15 16:30:42 Action: mPulse Channel Activity: Attempt to create queue 'rpieventuploadxxx183271Failed1':- Success

Indicates an attempt to create a new queue for SMS events just in case of any send failure. This queue will only create once during send execution.

2023/08/15 16:30:41 Action: mPulse Channel Activity: Fetching event upload batch from queue 'rpieventuploadxxx183271':- Success

Indicates an attempt to retrieve a batch of SMS events from the queue.

2023/08/15 16:30:41 Action: mPulse Channel Activity: Member list asynchronous import results:
Total Member list uploaded Successful: 5
Total Member list uploaded with Failures: 0
Total Member list uploaded with Invalid Phone Numbers: 0

The statistical report details of member list import.

  • Total Member list uploaded Successful. Total members have been imported to the list successfully.

  • Total Member list uploaded with Failures. Total members have been imported to the list unsuccessfully.

  • Total Member list uploaded with Invalid Phone Numbers. Total members have been imported to the list unsuccessfully due to invalid phone numbers.

2023/08/15 16:28:39 Action: mPulse Channel Activity: Member list import status: 0 out of 3 batch(es) uploaded. Will retry in 5 seconds...

Indicates the progress of member list batch import process. This log message will continue to poll every 5 seconds until the execution receives update.

2023/08/15 16:28:39 Action: mPulse Channel Activity: 1 seed SMS(s) have been sent

Indicates the number of seeds has been sent successfully.

2023/08/15 16:28:39 Action: mPulse Channel Activity: SMS campaign send results:
Exported 5 records successfully
Total member list batch(es) processed:- 3
Total member list batch(es) failed:- 0
Total event batch(es) successfully send to queue: 3
Total event batch(es) failed send to queue: 0

The statistical report details of member list upload and SMS events sent to the queue.

  • Total member list batch(es) processed. Indicates the total number batches have been processed for member list upload.

  • Total member list batch(es) failed. Indicates the total number batches have been processed, and it failed for member list upload.

  • Total event batch(es) successfully send to queue. Indicates the total number batches of SMS events have been sent to the queue.

  • Total event batch(es) failed send to queue. Indicates the total number batches of SMS events have failed to send to the queue.

2023/08/15 16:28:38 Action: mPulse Channel Activity: Member List Upload, batch #1:- Job Id=2dad5c5e-0f08-40cf-9b4b-4f25cc54e00b

Indicates that a batch of Member list is uploaded to mPulse via API call.

2023/08/15 16:28:38 Action: mPulse Channel Activity: Queue Event Upload (rpieventuploadxxx183271), batch #1 with 2 records:- Success

Indicates that a batch of SMS events is sent to the queue.

Troubleshooting

Enable trace option

When Enable trace option is selected within the Advanced tab of the mPulse channel configuration, the following samples of trace HTTP request/response log messages are generated:

Description

HTTP Request

HTTP Response

Connectivity Test and Queue Listener Sends

mPulse Channel Trace HTTP Request
Request Endpoint: https://ms-api.mpulsemobile.com/accounts/1485/members
Request Method: PUT

Version :6.6.0.0
FileVersion :6.6.23226.1
ProductVersion :6.6.23226.1 - Local Develop
DateTime :2023-08-23T05:34:55
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

Category: Plugin Trace
Priority: 10

mPulse Channel Trace HTTP Response
Request Endpoint: https://ms-api.mpulsemobile.com/accounts/1485/members
Request Method: PUT
Status: OK
Response Headers:
Connection: keep-alive
Date: Wed, 23 Aug 2023 05:34:56 GMT
Server: TornadoServer/3.2.2

Raw Content:
{"body": {"results": {"success": 1, "failure": 0}, "members": [{"member": {"id": {"mobilephone": "19787038966", "memberid": 108446742}, "result": "success", "profile": {"STATE": "Connecticut", "LASTNAME": "adam", "ZIP": "02482", "CONTENT": "[Title]", "FIRSTNAME": "Bethany@s", "RMENABLED": false, "MOBILEPHONE": "19787038966", "GENDER": "Male", "DATEADDED": "2023-05-09 18:25 PDT", "MEMBERID": 108446742}, "subscriptions": {"sms": {"status": "ACTIVE"}}}}]}}

Version :6.6.0.0
FileVersion :6.6.23226.1
ProductVersion :6.6.23226.1 - Local Develop
DateTime :2023-08-23T05:34:56
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

Category: Plugin Trace
Priority: 10
Severity: Information

Asynchronous Member Upload 

mPulse Channel Trace HTTP Request
Request Endpoint: https://ms-api.mpulsemobile.com/accounts/1485/members
Request Method: PUT

Version :6.6.0.0
FileVersion :6.6.23226.1
ProductVersion :6.6.23226.1 - Local Develop
DateTime :2023-08-23T05:34:55
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

Category: Plugin Trace
Priority: 10

mPulse Channel Trace HTTP Response
Request Endpoint: https://ms-api.mpulsemobile.com/accounts/1485/members
Request Method: PUT
Status: Accepted
Response Headers:
Connection: keep-alive
Date: Wed, 23 Aug 2023 05:22:58 GMT
Server: TornadoServer/3.2.2

Raw Content:
{"body": {"request_info": {"request_id": "3c46e4f4-8935-4659-b335-bb159ed98124"}}}

Version :6.6.0.0
FileVersion :6.6.23226.1
ProductVersion :6.6.23226.1 - Local Develop
DateTime :2023-08-23T05:22:58
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

Category: Plugin Trace
Priority: 10
Severity: Information

SMS Event Upload

mPulse Channel Trace HTTP Request
Request Endpoint: https://ms-api.mpulsemobile.com/account/1485/uploadEvent
Request Method: POST


Version :6.6.0.0
FileVersion :6.6.23229.1554
ProductVersion :6.6.20230817.23229 -- 18688_dev -- VSTS-Build
DateTime :2023-08-23T10:04:50
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

mPulse Channel Trace HTTP Response
Request Endpoint: https://ms-api.mpulsemobile.com/account/1485/uploadEvent
Request Method: POST
Status: OK
Response Headers:
Connection: keep-alive
Date: Wed, 23 Aug 2023 10:04:51 GMT
Server: TornadoServer/3.2.2


Raw Content:
{"body": {"result": {"status": "success", "message": "Upload Event is being processed in background. Status of processing is available on given URL.", "url": "https://ms-api.mpulsemobile.com/account/1485/uploadEventStatus?requestId=14857026b802032e4a4f9c9c1ea07dc3c9b0"}}}


Version :6.6.0.0
FileVersion :6.6.23229.1554
ProductVersion :6.6.20230817.23229 -- 18688_dev -- VSTS-Build
DateTime :2023-08-23T10:04:51
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

SMS Event Upload Status 

mPulse Channel Trace HTTP Request
Request Endpoint: https://ms-api.mpulsemobile.com/account/1485/uploadEventStatus?requestId=14857026b802032e4a4f9c9c1ea07dc3c9b0
Request Method: GET


Version :6.6.0.0
FileVersion :6.6.23229.1554
ProductVersion :6.6.20230817.23229 -- 18688_dev -- VSTS-Build
DateTime :2023-08-23T10:04:51
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

mPulse Channel Trace HTTP Response
Request Endpoint: https://ms-api.mpulsemobile.com/account/1485/uploadEventStatus?requestId=14857026b802032e4a4f9c9c1ea07dc3c9b0
Request Method: GET
Status: OK
Response Headers:
Connection: keep-alive
Date: Wed, 23 Aug 2023 12:51:28 GMT
ETag: "008a3f7430259f6224f747b48b3f53ff44585bf9"
Server: TornadoServer/3.2.2

Raw Content:
{"body": {"results": {"processed_event_instances": "1", "scheduled_messages": "1", "errors": "0", "details": {"listid": "9966", "events": {"event_definition_id": "4656", "event_definition_name": "RPI", "event": {"event_instance_request_index": "0", "correlationid": "50528444|15710|5501b580-fdc9-47ec-9d6d-b0034309a5cc", "memberid": "106298241", "event_instance_id": "369486219", "scheduled_messages": {"scheduled_message": {"message_id": "232595", "scheduled_datetime": "2023-08-23 12:51:33+00:00"}}, "errors": null}}}}}}

Version :6.6.0.0
FileVersion :6.6.23229.1554
ProductVersion :6.6.20230817.23229 -- 18688_dev -- VSTS-Build
DateTime :2023-08-23T12:51:28
TypeName :HttpClientLoggingHandler
TypeFullName :RedPoint.Plugins.Extensions.HttpClientLoggingHandler

Enterprise library logging

To add additional logging mechanism using the Enterprise library logging at the Callback Service web app level, please do the following:

  1. Rename the file below. You should find this file within mPulseCallbackServiceWebAPI\App_Config directory.

    from EnterpriseLibrary.Logging.ExceptionHandling.Example
    to EnterpriseLibrary.Logging.ExceptionHandling

    The file extension should remain the same.

  2. The callback service should be able to generate log files within the mPulseCallbackServiceWebAPI\App_Logs directory.

  3.  Perform status check of the callback service and make sure it is working as expected.
    To do this, you need to use either Fiddler trace or Postman by calling the API endpoint below using GET method.

    https://<HOST NAME OR IP ADDRESS>/mPulseCallbackServiceWebAPI/status/<CLIENT ID>

Common questions

Q

Which error codes are retry-able?

A

Timeout
ConnectFailure
SecureChannelFailure
ConnectionClosed
ProtocolError
ReceiveFailure
NameResolutionFailure
SendFailure
ServerProtocolViolation
KeepAliveFailure
GatewayTimeout
BadGateway
ExpectationFailed
RequestTimeout
NotFound
ServiceUnavailable
TooManyRequest

Q

What is the current re-try strategy employed if API requests to mPulse fail?

A

If API request fails, mPulse connector employed Exponential Backoff re-try strategy.
Normally, the interval of each attempt will exponentially increase the waiting time e.g., 1s, 2s, 4s... etc. until the max retry count has been reached. The number of attempts is configurable via API Call max. re-try setting in mPulse channel with default value of 10.

Q

What are the Queue providers supported for Event upload content queue path?

A

Azure ServiceBus/Storage Queue
ApacheMQ
AWS Queue
RabbitMQ

Q

What is the character limit of a message and what happens if the text for the SMS message exceeds the limit?

A

GSM (English template): 160 characters per segment. If over 160 characters, then there is an “invisible header” that utilizes 7 of those characters to concatenate the messages for reassembly. So, it reverts to 153 characters per segment.

UCS2 (Spanish) template: 70 characters per segment. If over 70 characters, then there is an “invisible header” that utilizes 3 of those characters to concatenate the messages for reassembly. So, it reverts to 67 characters per segment.

Most carriers and devices will not break up the segments into separate messages. Most smartphones & carriers now allow all the segments to display as one message.

Older devices, like a Nokia, will break them apart, and there are some smaller carriers that will still display each segment as a separate message.



JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.