UMS & MAC Application – Complete Technical Project Guide

A consolidated project, architecture, product-ownership, collection, mediation, EMS and MAC responsibility guide. This version incorporates the UMS product portfolio, four-stage processing model, conference mediation rules, MAC application responsibilities and collection source tables.

UMSCollectionMediationEMSMMPExtractionACEMetraTechIVR

1. UMS Overview & Terminology

UMS = Usage Management System, also called Mediation Management System. According to the attached document, UMS collects raw usage from bridges, databases and files, processes that usage and sends it to billing through MT / MetraTech.

Term	Purpose
UMS	Usage Management System that manages collection, mediation and extraction of usage.
ACE	Central InterCall database containing critical information for clients, products, reservations, company, account and owner.
Reference Database	Master/reference database for clients, products, reservations, company, account and owner data.
MetraTech (MT)	Billing platform through which usage is billed and billing reports are generated.
MetraNet	Billing destination referenced by feature and extraction processing in the source document.

2. UMS Product Ownership – 20+ Products / Integrations

As part of UMS, the responsibility covers a broad portfolio of file-based, REST, web-service, database and web-based products. The product type determines the collection adapter and the source-to-UMS ingestion mechanism.

20+Products / integrations under UMS responsibility

4Core UMS processing stages

5Primary source patterns: file, upload, DB, REST, WebService

2Major application areas: UMS & MAC

Product & Collection Responsibility Matrix

#	Product / Integration	Collection Type	Responsibility / Role in UMS
1	IVR	File Collection	Fetch source files and process IVR usage through the UMS pipeline.
2	Encore	File Collection	Source-file acquisition and downstream usage processing.
3	Adobe	Web Services	Consume usage through service integration.
4	WebEx	Web Services	Consume usage through web-service integration.
5	CCASP	REST Services	Collect usage through REST APIs.
6	DailyOafees	Database Collection	Collect usage from database source.
7	EOM Fees	Database Collection	Collect end-of-month fee data from database source.
8	IWS	Database Collection	Database-driven usage collection.
9	WESI	Database Collection	Database-driven usage collection.
10	ManualLeg – EMEA	File Collection	Manual leg file ingestion for EMEA.
11	ManualLeg – APAC	File Collection	Manual leg file ingestion for APAC.
12	MANUAL_EMEA_REKEY	File Collection	Re-key/manual correction file ingestion for EMEA.
13	MANUAL_APAC_REKEY	File Collection	Re-key/manual correction file ingestion for APAC.
14	MANUAL_UK_LINK	File Collection	Manual UK link file ingestion.
15	Manual Owner Features	File Upload	Upload owner feature records for UMS processing.
16	Manual Conference Features	File Upload	Upload conference feature records for UMS processing.
17	MP3	Database Collection	Database-based collection of MP3-related usage.
18	PostProcessing	Database Collection	Database-driven post-processing activity.
19	ums-wml-pexip	Database Collection	Database collection for WML/Pexip usage.
20	livemeeting	Web Services	Consume LiveMeeting usage through web services.
21	skypeForBusiness	Web Services	Consume Skype for Business usage through web services.
22	Mosiac	File Collection	Mosaic source-file collection.
23	mosiac-jiraps	File Collection	Mosaic JIRAPS file collection.
24	mosiac-legacy	File Collection	Mosaic legacy file collection.
25	mosiac-sms	File Collection	Mosaic SMS file collection.
26	mosiac-vf	File Collection	Mosaic VF file collection.
27	mosiac-wni	File Collection	Mosaic WNI file collection.
28	MMP	Web-based Application	Web-based application integrated with the wider UMS ecosystem.

Ownership statement: “As part of UMS, I was completely responsible for a portfolio of products covering file collection, database collection, REST APIs, SOAP/WSDL web services and manual file uploads. My responsibility extended from source acquisition through collection, mediation, event/error handling and downstream billing readiness.”

3. UMS Architecture & Four-Stage Processing Lifecycle

PreCollection

→

Collection

→

Mediation

→

EMS / Billing Readiness

1. PreCollection

Applies primarily to file-based products. Jobs fetch files from the external source and place them into the UMS local file system. This separates file acquisition from actual usage parsing and collection.

Connect to source / SFTP location.
Identify and fetch eligible files.
Store files in the UMS local file system.
Maintain collection/audit information where applicable.
Make the file available for the Collection phase.

2. Collection

Reads usage from the appropriate source: UMS local files, database, REST API or WSDL/SOAP web service, and stores raw data into UMS normalized and product-associated tables.

Parse source-specific data.
Apply source-to-UMS mapping.
Create product collected records.
Populate normalized records.
Generate audit/error information where required.

3. Mediation

Transforms, validates, completes and assembles collected usage into business-ready conference, participant and feature records.

Duplicate and late-leg handling.
Owner, conference and reservation validation.
Header/participant completion.
Bill code and surcharge determination.
Conference assembly and ready-for-billing processing.

4. EMS & Downstream Billing

EMS manages event/error cases and audit history. Successful usage continues toward extraction and the billing platform.

Create auditable EMS cases for event/error conditions.
Maintain multiple historical cases per session.
Complete billing-readiness checks.
Extract processed usage to downstream billing tables.

Source-to-Billing Conceptual Flow

Source Files

Source DB

REST API

SOAP/WSDL

Manual Upload

↓

PreCollection

→

Collection

→

Normalized UMS Data

→

Mediation

→

EMS / Ready for Billing

→

Billing

6. PreCollection – File Acquisition

PreCollection is the file-ingestion preparation stage. For file-based products, the job does not immediately perform all business processing. It first obtains the source file and stores it in the UMS local file system so that the Collection job can consume it in a controlled manner.

Step	Activity	Purpose
1	Source connection	Connect to the configured external file source, commonly an SFTP/file location.
2	File discovery	Identify files eligible for the current processing window.
3	File acquisition	Fetch/copy files from the source.
4	Local persistence	Store files in the UMS local file system.
5	Handoff	Make the acquired file available to the Collection job.
6	Audit / error handling	Track collection outcome and route failures for operational support where applicable.

Interview wording: “For file-based products, we have a PreCollection stage where the source files are fetched and stored in the UMS local file system. The Collection stage then reads those local files and converts the source data into product-specific and normalized UMS records.”

5. Collection Phase

Definition: Collection is the mechanism or process to fetch raw usage from bridges, databases or files. It is the entry point into the UMS processing pipeline.

Main Responsibilities

Fetch raw conference and usage information from external sources.
Support file collection, database collection and bridge collection.
Persist raw usage into product-specific collected tables.
Create normalized records required by mediation.
Create optional EMS and file collection audit records where applicable.

Bridges

Databases

Files

↓

Collection Process

→

Collected Tables

→

Normalized Tables

→

Mediation

Optional EMS Case

Optional File Collection Log

6. Collection Sources

File CollectionUsage is collected from source files. Every file collection job is audited through the file collection log.

Database CollectionUsage is fetched directly from source databases and inserted into the UMS collection flow.

Bridge CollectionConference bridge usage is collected as raw usage. The attached document illustrates IVR as a bridge source.

Project IntegrationsThe earlier project explanation included Adobe and Webex web services plus CCASP REST APIs as project-specific collection adapters. Keep these as integrations you actually worked with.

7. Collected, Normalized & Optional Tables

The source document states that Collection inserts usage into three categories of tables.

Table Type	Purpose	Example
Collected Tables	Store raw usage for each product.	`ums_ivr_usage_part`
Normalized Tables	Store normalized records used throughout mediation and extraction.	Session Control, Header, Participant, Feature
Optional Tables	Store event/error and collection audit information.	`ems_case_rcd`, `ums_file_collection_log`

For every product, raw usage is saved into an associated product collected table. The document specifically gives IVR usage stored in ums_ivr_usage_part.

8. Normalized Records

Session Control Record

The Session Control Record controls the mediation process for a conference or standalone feature from collection through extraction for billing. The source highlights Status Flag, Conference Event Type, Conference Event Code and Supersede Flag as the fields that indicate processing state.

Conference Header Record

The Conference Header contains information common to all participant legs and conference features within a conference. It is created when a collected event contains multiple participant records. If required, the source describes creating a header using ACE reservation information.

Participant Record

Participant Records represent individual user usage within a conference or event. Usage duration based on start and end time is important for billing. Since several service types use this format, not every field is populated for every record.

Feature Record

Feature Records represent non-recurring charges that flow through mediation before billing. The source distinguishes conference feature records associated with reserved conferences and owner feature records associated with an owner number. Both use the common ums_feature structure and are identified by record_type.

9. Optional Tables

EMS Case Record – `ems_case_rcd`

Created when a session is sent to EMS for event or error processing.
Remains open until the clear time is entered.
Multiple EMS cases can exist for the same ums_session_id.
Historical cases are retained to preserve a complete audit trail.
A new case is opened whenever a new event condition occurs.

File Collection Log – `ums_file_collection_log`

Every file-based collection job creates one log entry. The status identifies whether the job completed successfully, processed an empty file or encountered an error.

10. IVR Collection

IVR = Interactive Voice Response History. The document describes IVR as a separate bridge (bridge type ID 4) used for Operator Assisted and Automated calls involving Spectel and Compunetix bridges.

IVR usage is collected as participant usage legs.
IVR is billed as audio for North America and APAC according to the source.
If conference audio and IVR occur in the same month, both are grouped into one conference.
If IVR occurs in later months after the audio conference has already been billed, only IVR legs are shown for that conference.

IVR

→

Collection

→

Collected + Normalized

Transformation

→

Validation

→

Mediation

→

EMS

Usage Ready for Billing?

Yes →

Extraction

→

MetraNet Tables

11. Local Fetch

The operational pages in the attached document illustrate Local Fetch using the UMS environment, an SFTP client, CDR files and the UMS Web UI.

Configured Trigger

→

Connect to SFTP

→

Browse CDR Files

→

Launch IVR Collection Job

↓

Collection Completed

→

Launch IVR Mediation Job

→

Verify Session Control Counts

Operational interview explanation: “For IVR Local Fetch, we connected to the configured SFTP location, collected the CDR files, launched the IVR Collection Job through the UMS Web UI, launched the Mediation Job and finally validated the resulting Session Control status and event counts using database queries.”

12. Remote Fetch

The source document defines date behavior specifically for Remote Fetch.

Input	Behavior
Specified collection date	Fetch usage for that exact date.
No date supplied	Generally collect T-1 day usage.
Blank / Empty date	Read the last collected date from the database and fetch usage from that date onward.

Important: This date-selection logic applies only to Remote Fetch according to the attached document.

13. Mediation Overview

The source establishes that normalized records are used by mediation to control the conference lifecycle from collection through extraction for billing.

Read normalized usage created during collection.
Use Session Control to identify processing state.
Process conference, participant and feature records.
Apply business processing before extraction.
Route sessions requiring event/error handling into EMS.

13. Standard Mediation Processing for Conferences

Mediation is the core business-processing layer where collected usage is transformed into complete, validated and billable conference data. The following rules represent the conference processing responsibilities provided for this project.

13.1 Standard Transformation Processing

Conference Duplicate Processing

Complete Duplicate: identify and handle a conference that is fully duplicated.
Child Conference with Missing Legs: handle partial duplicates where the child conference does not contain the full set of legs.
Late Legs: process legs arriving after the original conference, including child conferences that overlap with the parent but introduce new legs and child conferences containing the same conference ID with entirely new legs.
Hybrid Duplicate: resolve cases where parent and child conference legs do not match.

Recorder & Test-Number Processing

Identify the recorder line and populate the Recorder Participant Type.
For IICP, Spectel and Compunetix, scrub calls to DNIS test numbers.

13.2 Standard Validation Processing

Validation	Purpose
Owner Number Validation	Validate owner information before the usage proceeds through the billing lifecycle.
ACE Conference ID & Reservation Call Type Validation	Validate conference/reservation information for Spectel OA, Compunetix OA, IVR and Encore scenarios.

13.3 Conference Header Completion

Conference Header completion populates the common conference-level attributes required for downstream processing. Key completion areas include:

PAC CodePopulate PAC when collected from the source; apply the defined behavior when no PAC is collected.

NamesComplete Leader Name and Reservation Name.

Reservation ContextResolve Reservation Time Zone and Account Number.

OrganizationPopulate Business Unit ID, Company Number/Name and Office Code.

PricingDetermine Pricing Model for IICP, IUM, Spectel and Compunetix Summit (non-OA).

UMS IdentityPopulate the UMS Conference ID.

MMM / PCEApply MMM and PCE setup for applicable IICP, Spectel and Compunetix Summit audio conferences.

OA ResolutionResolve premium billing and ACE reservation data for Spectel OA and Compunetix OA.

13.4 Participant Completion

Compute alternative durations for participant records.
Evaluate participant leg completion errors.
Scrub conferences that do not contain extractable legs.

13.5 Bill Code & Surcharge Processing – Outbound

Processing Area	Examples / Rules Covered
Base Bill Code / Bill Code	Determine applicable codes for outbound calls.
Domestic – US & Canada	Apply domestic surcharge logic.
Domestic – EMEA / APAC	Apply regional domestic surcharge logic.
NANP International	Handle US/CA NANP international scenarios.
International	Handle US, Canada, EMEA and APAC international calls.
Resless	Determine Base Bill Code and Bill Code for IICP, Spectel and Compunetix Resless.
OA	Determine Base Bill Code and Bill Code for Spectel OA and Compunetix OA.

13.6 Additional Standard Completion Rules

Resolve International Flag and Originating Country Code for IICP, Spectel and Compunetix.
Replace interim UMS codes with values acceptable to MetraNet.
Replace Bill Code for MobileMeet participants where applicable.
Resolve Participant Line Name.
Resolve Conference Type for OA services.
Determine Base Bill Code, Bill Code and Surcharge Code for inbound calls.
Resolve Product Type for Spectel OA, Compunetix OA and MMP Manual Leg Entry.
Process LATAM Hybrid Event Bundles and LATAM iER Direct Event Bundles for OA Instream and OA Instream Reconciliation Features.

14. Standard Usage / Conference Assembly & Ready-for-Billing

14.1 MMM Processor for IUM Consolidation

Query the UMS Web Audio Synchronization Table for MMM conferences.
Create the MMM Status Record.
Create a new Session Control Record for the MMM conference.
Create the Conference Header Record.
Merge Participant Detail Records.
Compute alternative durations.
Create supplemental participant records.
Update the status of the original conferences.
Create the UMS Feature Record for IUM MMM conferences.
Forward the MMM conference to the Ready-for-Billing process.

14.2 Ready-for-Billing Processing

Residual Error CheckVerify that no unresolved residual errors remain before billing.

Last-Minute Error CheckPerform final validation immediately before the usage becomes billing-ready.

Superseded ConferenceProcess conferences that supersede an already completed core-mediation conference.

Associated ConferenceProcess conferences associated with a previously completed conference.

Ten-Minute RuleDetermine eligibility and process applicable audio conferences.

OA Conference MergingDetermine merging eligibility and process conferences requiring OA merging.

Premium ReprocessingReprocess premium billing for OA-merged conferences when required.

15. Standard UMS Processing for Features

Area	Processing
Feature Validation	Validate standard feature records before completion.
Owner Number Validation	Validate owner number for owner and conference features.
ACE Conference ID Validation	Validate ACE Conference ID for conference features.
PAC Code	Complete PAC Code for owner features.
Company	Complete Company Number and Company Name for owner features.
Business Unit	Complete Business Unit ID for owner features.
Office	Complete Office Code for owner features.

Feature perspective: Conference features and owner features use the UMS feature-processing model, with validation and completion rules applied before the records are ready for downstream processing.

16. EMS – Event Management System

EMS is connected to event and error processing through the EMS Case Record.

Receive sessions requiring event or error processing.
Create and maintain auditable EMS cases.
Support multiple cases for the same session when new event conditions occur.
Preserve historical event information instead of overwriting it.

17. MAC Application – Responsibilities & Functional Areas

MAC is a separate major responsibility area alongside UMS. The MAC application manages data collection/distribution flows between ACE and MetraNet, scheduled/manual batches, one-off validation and processing, and end-of-month synchronization jobs.

17.1 Core MAC Functionalities

Functionality	What It Does	Typical Use
Queue Flows	Handle collection and distribution of MAC data, including audits and events.	ACE → MetraNet and MetraNet → ACE audit/event flows.
Batch Flows	Allow users to schedule the time each day when MAC batches are fired. Users can also manually run a batch at any time.	Daily scheduled processing or operational re-run.
Validate One	Quickly test whether an entity was successfully passed from ACE to MetraNet.	Validate Office, Company, Account, Owner and similar entities.
Process One	Manually push data to create or update entities.	Manual create/update of Office, Company, Account, Owner and similar entities.
EOM Jobs	Run script-based batch jobs at end of month and before the billing run.	Ensure ACE and MetraNet metadata remain synchronized.

17.2 MAC Processing Concept

ACE Data

→

Queue / Batch

→

Validate / Process

→

MetraNet

Audit

Events

EOM Jobs

Manual Re-run

17.3 MAC Operational Responsibilities

Monitor scheduled Queue and Batch flows.
Execute batches manually when operational recovery or reprocessing is required.
Use Validate One for fast entity-level verification.
Use Process One for controlled manual entity creation/update.
Run and monitor EOM scripts before billing to maintain ACE and MetraNet metadata synchronization.
Use collection/audit tables to investigate missing, delayed or incorrectly distributed data.

18. MAC Collection Source Tables

The following source tables support MAC collection and audit/distribution processing.

Table	Description	Functional Area
`ace_audit_collect`	ACE Audit Collection	Audit / synchronization
`ace_res_collect`	ACE Reservation Collection	Reservation data
`ace_event_collect`	ACE Event Collection	ACE events
`mnet_event_collect`	MetraNet Event Collection	MetraNet events
`ace_rp_feat_collect`	Resplus Features Collection	Features
`ace_rec_charge_collect`	ACE MetraNet Recurrent Charges Collection	Recurring charges
`named_user_collect`	Named User Subscription Collection	Named-user subscriptions
`ace_division_collect`	ACE Division Collection	Organizational hierarchy
`ace_region_collect`	ACE Sales Region Collection	Sales-region data
`ace_emp_sales_rep_collect`	ACE Employee Sales Rep Collection	Employee / sales-rep data
`ace_bill_resell_type_collect`	ACE Bill Reseller Collection	Billing / reseller information

MAC interview statement: “In MAC, I was responsible for Queue Flows, Batch Flows, Validate One, Process One and EOM Jobs. The application supports ACE-to-MetraNet data synchronization, audit/event collection, scheduled and manual batch execution, entity-level validation and controlled end-of-month metadata synchronization before billing.”

19. Extraction & Billing

Normalized Usage

→

Mediation

→

Extraction

→

MT / Billing Tables

Extraction prepares processed usage for billing. The source references billing through MT / MetraTech and also describes feature records being extracted into appropriate MetraNet billing tables.

20. Operational Validation & Controlled Cleanup

Validation

The document demonstrates validating processed data by grouping Session Control records using fields such as status_flag, conf_event_code, conf_event_type, source and partition date. This helps verify the processing distribution after Collection and Mediation.

Cleanup

The last page contains operational DELETE statements for IVR-related usage, feature/session records, EMS cases and file collection logs before controlled reprocessing. In documentation and interviews, present this as a controlled test/support cleanup procedure rather than a general production operation.

21. Updated 2–3 Minute Interview Explanation

Project Explanation

I worked on a Usage Management System called UMS. As part of UMS, I was responsible for a broad portfolio of products covering file collection, database collection, REST services, WSDL/SOAP web services and manual uploads. The overall purpose was to collect raw usage, normalize it, apply business mediation rules, manage event and error cases through EMS and make the usage ready for downstream billing.

The Collection phase was the entry point. It collected raw usage from file-based sources, database sources and conferencing bridges. In my project, external integrations also included Adobe and Webex web services and CCASP REST services. The collected raw usage was stored in product-specific collected tables, and normalized records were created for downstream processing.

The normalized layer contained Session Control, Conference Header, Participant and Feature records. Session Control controlled the lifecycle from collection through extraction, Conference Header represented common conference information, Participant represented individual usage legs and Feature records handled non-recurring charges.

For file collection, every job was tracked in the file collection log. If a processing event or error occurred, EMS created an EMS Case Record and preserved the complete audit history by allowing multiple cases for the same UMS session.

The IVR flow supported Local Fetch and Remote Fetch. Local Fetch operationally connected to the configured SFTP location, collected CDR files and launched Collection and Mediation jobs through the UMS Web UI. Remote Fetch supported explicit dates, default T-1 collection and blank-date recovery using the last collected date stored in the database.

Alongside UMS, I was responsible for the MAC application. MAC handled Queue Flows, Batch Flows, Validate One, Process One and EOM Jobs. Queue and batch flows supported ACE-to-MetraNet data collection/distribution and audit/event processing; Validate One and Process One supported entity-level operational checks and manual create/update; and EOM Jobs helped keep ACE and MetraNet metadata synchronized before billing.

Finally, Extraction prepared processed usage for billing through MT / MetraNet. In simple terms: PreCollection acquires files, Collection ingests source usage, Mediation transforms and validates it, EMS manages event/error cases, MAC synchronizes operational metadata, and the downstream process delivers billing-ready usage.

22. Quick Revision Sheet

Area	Remember
UMS	Usage Management System / Mediation Management System.
Collection	Fetch raw usage from bridges, databases and files.
Collected Tables	Store raw product usage.
Normalized Tables	Session Control, Header, Participant and Feature records.
Optional Tables	EMS Case and File Collection Log.
IVR	Separate bridge with Local Fetch and Remote Fetch.
Remote Fetch	Specified date, T-1 default or last collected date recovery.
Mediation	Process normalized usage for the billing lifecycle.
EMS	Auditable event and error processing.
Extraction	Prepare processed usage for MT / MetraTech / MetraNet billing.
MAC	Queue Flows, Batch Flows, Validate One, Process One and EOM Jobs for ACE ↔ MetraNet synchronization.
MAC Tables	ACE audit, reservation, event, feature, recurring charge, named-user, division, region, sales-rep and reseller collections.

UMS & MAC Application – Complete Technical Project Guide

Contents

1. UMS Overview & Terminology

2. UMS Product Ownership – 20+ Products / Integrations

Product & Collection Responsibility Matrix

3. UMS Architecture & Four-Stage Processing Lifecycle

1. PreCollection

2. Collection

3. Mediation

4. EMS & Downstream Billing

Source-to-Billing Conceptual Flow

6. PreCollection – File Acquisition

5. Collection Phase

Main Responsibilities

6. Collection Sources

7. Collected, Normalized & Optional Tables

8. Normalized Records

Session Control Record

Conference Header Record

Participant Record

Feature Record

9. Optional Tables

EMS Case Record – ems_case_rcd

File Collection Log – ums_file_collection_log

10. IVR Collection

11. Local Fetch

12. Remote Fetch

13. Mediation Overview

13. Standard Mediation Processing for Conferences

13.1 Standard Transformation Processing

13.2 Standard Validation Processing

13.3 Conference Header Completion

13.4 Participant Completion

13.5 Bill Code & Surcharge Processing – Outbound

13.6 Additional Standard Completion Rules

14. Standard Usage / Conference Assembly & Ready-for-Billing

14.1 MMM Processor for IUM Consolidation

14.2 Ready-for-Billing Processing

15. Standard UMS Processing for Features

16. EMS – Event Management System

17. MAC Application – Responsibilities & Functional Areas

17.1 Core MAC Functionalities

17.2 MAC Processing Concept

17.3 MAC Operational Responsibilities

18. MAC Collection Source Tables

19. Extraction & Billing

20. Operational Validation & Controlled Cleanup

Validation

Cleanup

21. Updated 2–3 Minute Interview Explanation

22. Quick Revision Sheet

EMS Case Record – `ems_case_rcd`

File Collection Log – `ums_file_collection_log`