Home
MATRIXX Configuration
Configuring MATRIXX Using Helm
Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.
Component-Specific Sub-Chart Properties
Each MATRIXX Helm sub-chart has component-specific properties.
RS Gateway
docker_kubernetes/c_config_helm_comp_spec_rsgwy.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the RS Gateway sub-chart.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
- About MATRIXX Configuration
  MATRIXX Configuration describes the tasks required to configure MATRIXX components.
- Configuring MATRIXX Using Helm
  Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.
  - Managing Helm Values Files
    In complex installations it may be necessary or helpful to use more than one Helm values file. The helm install and helm upgrade commands can accept multiple values files, with values in files listed later taking precedence. Layering Helm values files in this way can be used to reduce duplication.
  - MATRIXX Helm Chart Properties
    The MATRIXX Helm chart, and by extension a cloud native MATRIXX deployment, are configured using a Helm values file or files.
  - Topology Operator Configuration
    For information about Topology Operator configuration, including Topology Operator-related health checking, pricing, tax, and multi-tenancy configuration, see the discussion about Topology Operator configuration in MATRIXX Installation and Upgrade.
  - Common Sub-Chart Properties
    Each MATRIXX component has an corresponding Helm sub-chart that can be configured from the main chart.
  - Component-Specific Sub-Chart Properties
    Each MATRIXX Helm sub-chart has component-specific properties.
    - Engine
      docker_kubernetes/c_config_helm_comp_spec_eng.html#c_config_helm_comp_spec_eng__table_llp_wdp_ylb describes the configuration options available in the MATRIXX Engine sub-chart.
    - Traffic Routing Agent
      docker_kubernetes/c_config_helm_comp_spec_tra.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the Traffic Routing Agent (TRA) sub-chart.
    - Network Enabler
      docker_kubernetes/c_config_helm_comp_spec_ne.html#c_config_helm_comp_spec_tra2__table_llp_wdp_ylb describes the configuration options available in the Network Enabler (NE) sub-chart.
    - Pricing Controller
      docker_kubernetes/c_config_helm_comp_spec_pc.html#c_config_helm_comp_spec_pc__table_llp_wdp_ylb describes the configuration options available in the Pricing Controller sub-chart.
    - SNMP Exporter
      There are no component-specific configuration options available for the SNMP Exporter chart.
    - Gateway Proxy
      docker_kubernetes/c_config_helm_comp_spec_gw_p.html#c_config_helm_comp_spec_tra3__table_llp_wdp_ylb describes the configuration options available in the Gateway Proxy sub-chart.
    - ActiveMQ Gateway
      docker_kubernetes/c_config_helm_comp_spec_activemq.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the ActiveMQ Gateway sub-chart.
    - RS Gateway
      docker_kubernetes/c_config_helm_comp_spec_rsgwy.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the RS Gateway sub-chart.
    - Payment Service
      docker_kubernetes/c_config_helm_comp_spec_ps.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the Payment Service sub-chart.
    - Event Stream Server
      docker_kubernetes/c_config_helm_comp_spec_es.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the Event Stream Server sub-chart.
    - Notification Server
      docker_kubernetes/c_config_helm_comp_spec_notifier.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the Notification Server sub-chart.
    - LDAP Gateway
      docker_kubernetes/c_config_helm_comp_ldap_gateway.html#concept_f4y_v5m_wmb__table_llp_wdp_ylb describes the configuration options available in the LDAP Gateway sub-chart.
    - MATRIXX Backoffice Customer Tool
      docker_kubernetes/c_config_helm_comp_spec_bct.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the MATRIXX Backoffice Customer Tool sub-chart.
    - My MATRIXX
      docker_kubernetes/c_config_helm_comp_spec_mm.html#c_config_helm_comp_spec_tra__table_llp_wdp_ylb describes the configuration options available in the My MATRIXX sub-chart.
    - SBA Gateway CHF Component
      docker_kubernetes/c_config_helm_comp_spec_sba.html#c_config_helm_comp_spec_sba__table_llp_wdp_ylb describes the configuration options available in the SBA Gateway sub-chart.
    - SBA Gateway Kafka Producer Write to Disk Logging Function
      When SBA Gateway streams _glossary/cdr.html data to Kafka, the Write to Disk logging function writes each CDR to a log file in a persistent volume (PV) when the Kafka broker is not available. When access to Kafka is restored, records on disk can be replayed using the cdr-kafka-replay microservice.
    - General Ledger Processing and Posting Components
      Use these configuration properties to configure the General Ledger Processor and General Ledger Posting CHF components.
- Configuring MATRIXX Engine
  MATRIXX Engine configuration can be applied from a configuration source.
- Configuring Traffic Routing Agent
  Traffic Routing Agent (TRA) configuration can be added to the deployment with a configuration source.
- Configuring Sub-Domain Routing (Multiple Sub-domains)
  In a MATRIXX environment where multiple customer sub-domains are implemented in separate engine chains, you configure sub-domain routing so that traffic is directed to the correct customer sub-domain where the subscriber is homed. You must configure different components across MATRIXX for sub-domain routing to work.
- Example Single Domain Deployments
  Example configurations are provided for single-engine, dual-engine, and dual-engine with Traffic Routing Agent in disaster recovery mode (TRA-DR) cloud native MATRIXX examples.
- Configuring MATRIXX Gateways and Web Apps
  In a non-containerized installation of MATRIXX, configure MATRIXX gateways and web apps using files in the /opt/mtx/conf directory in the pod(s) hosting those components. In a cloud native deployment, configuration files can be provided in the /opt/mtx/conf directory of the component container(s) using the following methods:
- Configuring CDR Processing
  The MATRIXX Engine can import and rate Solution42® call detail records (CDRs) and generate MATRIXX Event Detail Records (EDRs) from them. Generally, this is used only when integrating with an Oracle BRM system. Other projects should use external mediation to convert external CDRs into Diameter messages for MATRIXX processing.
- Configuration Input Settings
  In a cloud native MATRIXX installation, MATRIXX Engine configuration specified in the create_config.info file is applied with a configuration source. This file contains a list of the questions asked by the configuration script during the configuration process and the answers provided by the administrator. Each question sets a configuration parameter. The engine(s) are configured with these parameters with a helm upgrade command.
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

RS Gateway

RS Gateway Properties describes the configuration options available in the RS Gateway sub-chart.

Table 1. RS Gateway Properties
Property	Description
rsgateway.connections.gatewayProxy.host	The host name to use when connecting to the Gateway Proxy. The default value is `gateway-proxy-access-group`.
rsgateway.connections.gatewayProxy.port	The port to use when connecting to the Gateway Proxy. The default value is 4080.
rsgateway.autoSetRouteId	When set to `true`, in multi-domain installations the request routing ID is set to the value of the `domains.id` property. The default value is `false`. For more information, see the discussion about domain, sub-domain, and engine topology configuration in MATRIXX Configuration.
rsgateway.probes.scheme	If the RS Gateway is configured to use HTTPS, you must set this property to HTTPS because the HTTP liveness and readiness probes on the pod do not accept HTTP traffic in this case. The default value is HTTP.
rsgateway.security.certificate.secretName	The name of an existing Kubernetes secret object that is visible to the installation. See the discussion about using Kubernetes secrets for RS Gateway TLS certificates in MATRIXX Security. Note: The `rsgateway.security.certificate.volumeMountPath` property must also be configured.
rsgateway.security.certificate.volumeMountPath	The directory in the pod where the pod mounts the secret files, for example, `/etc/tls`. Note: The `rsgateway.security.certificate.secretName` property must also be configured.
rsgateway.mongodb.connectionString	This value overrides the `global.mongodb.connectionString` property. Note: MongoDB event loader must be enabled. For more information about the global MongoDB settings, see the discussion about MongoDB event loader configuration.

Note: The autoSetRouteId property uses the first domain ID in the list of domains in your Helm values file to set the request routing ID. For example, if a RS Gateway instance is meant to handle traffic for engines in domain 2, domain 2 must appear first in the Helm values file:

topology:
  domains:
  - id: 2
    subdomains:
    ...
  - id: 1
    subdomains:
    ...