Ameren Script Editing Portal & Public API

1. Overview

Ameren uses a dedicated Script Editing Portal (SEP) together with a Public API to process ad hoc customer communications. The Public API receives payloads, the platform identifies the applicable template and delivery channel, and messages are routed through RabbitMQ for email, SMS, or voice processing. The SEP is primarily used to manage templates, review message volumes/results, and investigate individual Message Broadcast IDs (MBIDs).

This workflow is distinct from EONS2. SEP/Public API is an ad hoc, API-driven messaging flow; EONS2 is used when Ameren needs to create and launch campaign-based communications using a dataset.

2. Scope and Support Responsibilities

• Understand the end-to-end Public API → queue → consumer → provider/result flow.
• Use the Results screen to validate daily message volumes and processing outcomes.
• Use MBID lookup and database records to investigate a specific payload/message.
• Validate template selection using company code, type, subtype, and supported channel.
• Do not change business-managed switchboard/campaign configurations unless explicitly authorized

3. Key Components

Component	Purpose
Ameren Public API	Receives ad hoc message payloads from Ameren.
Central Producer / Main Queue	Accepts the request and performs routing/segregation.
RabbitMQ	Queues messages for asynchronous processing.
Channel Consumers	Separate consumers process email, SMS, and voice.
Script Editing Portal (SEP)	Manages templates and provides results/lookups.
Provider / Dialer	Delivers the final SMS, email, or voice communication.
Disposition Data/File	Returns processing results to Ameren periodically.
EONS2	Campaign-oriented messaging platform.

 

4. High-Level Architecture and Message Flow

1. Ameren invokes a Public API endpoint and submits a message payload.
2. Authentication is performed before the request is accepted.
3. The platform generates an MBID (Message Broadcast ID) for the payload.
4. The centralized producer places the request into the main queue.
5. The request is evaluated to determine template and channel requirements.
6. Messages are segregated into email, SMS, and/or voice queues.
7. Channel-specific consumers pick up the queued records.
8. The applicable template is resolved, and dynamic placeholders are populated from payload data.
9. The consumer sends the communication to the downstream provider/dialer.
10. Sent and result records are written to channel-specific tables; result/disposition data is later returned to Ameren.

Public API → Main Queue → Channel Queue → Consumer → Template Resolution → Provider/Dialer → Result/Disposition

https://mbroadcast.atlassian.net/wiki/spaces/AM/overview --> Confluence page for reference

5. Template Management and Selection

Templates must exist before corresponding payloads can be processed successfully. The core template selection keys are Company Code, Type, and Subtype. Channel applicability is configured for the type/subtype combination; not every template necessarily supports all three channels.

• Company Code: identifies the Ameren company/entity, including Illinois or Missouri.
• Type: identifies the business notification category.
• Subtype: further identifies the notification variation.
• Channel: identifies whether SMS, email, and/or voice is supported.
• Placeholders: dynamic values in the template are replaced using values from the incoming payload.

For email templates, the configuration may include subject, from-address, and body. SMS templates contain the message body, while voice uses the applicable voice configuration/template.

6.  Alternate vs Preference Channel

Ameren payloads can identify recipients in two general ways. In an alternate-channel request, the payload provides the destination contact information directly. In a preference-channel request, Ameren provides an account number and the platform resolves the appropriate customer contact/preferences from stored customer preference data for the relevant company/type/subtype.

Mode	Payload Behavior	Typical Support Check
Alternate channel	Destination email/phone information is supplied directly in the payload.	Validate the supplied contact and payload data.
Preference channel	Account number is supplied; system resolves stored communication preferences.	Validate account number and preference/customer setup.

7. Script Editing Portal – Support Functions

7.1 Results / Summary Screen

The Results screen is the primary day-to-day support view. It can be used to confirm the volume of requests received and the corresponding channel processing counts for a selected date, company, type, subtype, or other available filter.

• Prefer a narrow date range, ideally a single day or a few days.
• Avoid broad queries because the screen reads production data and large ranges can affect performance.
• Use filters to isolate the relevant company/type/subtype rather than querying unnecessary data.
• Use this screen first when the question is whether Ameren sent data and how much was processed.

7.2 MBID Lookup

MBID is the primary correlation identifier generated when a Public API payload is accepted. The MBID lookup can show the received payload, processing details, channel activity, errors, and—where available—the disposition/batch information associated with the result returned to Ameren.

• Confirm that the MBID belongs to the environment being queried (QA vs Production).
• Review the payload and any displayed error before moving to deeper database investigation.
• Use the MBID to correlate the primary message record with email/SMS/voice records and results.

7.3 Campaign Switchboard

The Campaign Switchboard contains business-controlled settings for certain critical notification flows, including credit/collection-related communications. It can control time windows, volumes/batches, and whether features such as agent transfer are allowed. These settings are generally managed by Ameren/business users and are not routine Tier-1 and Tier - 2 configuration tasks.

8. Database Investigation

The message table is the primary starting point for database investigation. After the main message record is created/released, channel-specific records are written for email, SMS, and voice, followed by corresponding result records as downstream results are received.

Record Area	What It Indicates	How to Use It
Messages table	Primary record for the received payload/MBID.	Start here to confirm ingestion and inspect errors.
Email sent / result	Email was prepared/sent and whether a downstream result returned.	Compare sent vs result state.
SMS sent / result	SMS was prepared/sent and whether a delivery/result status returned.	Check provider/result status and timing.
Voice sent / result	Voice call was initiated and whether a result returned.	Validate dialer activity and result.

Note: a sent record without a result does not automatically mean the original API request failed. It may indicate that the downstream result has not yet been received. Correlate timestamps, provider status, and disposition processing before concluding the failure point.