ACRM Format XML “cat” Attributes Show 0 or Unexpected Values (DataModel / TenantRight)

Solution

Symptoms (how to recognize the issue)

• The exported/serialized format XML contains catalog attributes with unexpected values, for example: "cat attributes contains stranges values (0 or unknonwn numbers)".
• Expected catalog IDs (examples: cat=5001, cat=5002, cat=400) appear instead as 0 or other unexpected numeric values.
• This is commonly observed when reading formats via the SDK (for example using IFormatsService.ReadContents(...)) and serializing the returned XML (e.g., via an XML OuterXml serialization flow).

Key finding

The XML returned by IFormatsService.ReadContents() (and related format export flows) represents format definitions. It is not an authoritative catalog dictionary.

• Do not build Catalog ID → Catalog name mappings from cat attributes in exported format XML.
• Instead, extract catalogs from core catalog sources and join that catalog data to your exported formats as needed.

Recommended approach: export catalog definitions with mmba.exe and parse them

Step 1 — Configure mm.ini for XML export

On the CRM server, update mm.ini (commonly located under system/sys/mm.ini) to support predictable XML output naming and language tagging:

• xml_unique_filename
• xml_lang

Note: Exact value conventions depend on your environment standards. The key requirement is enabling unique filenames and language tagging in the generated XML output.

Step 2 — Export variable catalog definitions per language

Run mmba.exe to export catalog definitions to XML (repeat per language as needed):

mmba.exe -writexmldef -l0
mmba.exe -writexmldef -l1

This produces XML output containing catalog identifiers and their display names per language.

Reference: https://support.acrm.aurea.com/article/3153

Step 3 — Parse the generated XML into a “catalog dictionary” mapping table

Parse the mmba.exe-generated XML and load it into your external store (for example, a database table or an in-memory map), such as:

• Catalog ID (catalog number)
• Catalog name/text (per language, if required)

The referenced knowledge base article provides an example approach for extracting variable catalog names and loading them into an external database for lookup.

Reference: https://support.acrm.aurea.com/article/3153

Step 4 — Optional: export fixed catalog values (code/value lists)

If your integration also needs fixed catalog values (code/value lists), export those using the documented fixed-catalog export method:

Reference: https://support.acrm.aurea.com/article/3247

Step 5 — Continue exporting formats, but resolve catalog names via the exported dictionary

You can continue exporting DataModel/TenantRight formats as you do today (for example, via SDK format reads), but:

• Do not use the format XML cat=... attributes as the source of “catalog name” (or as a reliable catalog dictionary).
• Resolve catalog identifiers against the mmba-derived catalog dictionary (and fixed-catalog exports where applicable).

Tenant-Specific Visibility

Tenant visibility is enforced by rights/tenant configuration. If your requirement is similar to “Tenant A can read only those BB entries,” do not infer catalog entry visibility from format XML definitions alone.

• Evaluate visibility by reading/querying using the same tenant/user execution context your integration will use.
• Do not assume that visibility rules can be derived solely from exported DataModel/TenantRight XML.

Validation (how to confirm it’s working)

1. Run mmba.exe -writexmldef -l<lang_id> and confirm the output XML includes catalogs with IDs and human-readable names.
2. Parse the exported XML and verify your mapping contains expected pairs, for example:
   • <expected_catalog_id> → <expected_catalog_name>
3. In your integration/export pipeline:
   • Export formats as before.
   • Use the mapping table to translate catalog IDs to names (and fixed values, if applicable).
4. Confirm that catalogs that previously appeared as 0 in format XML can now be correctly identified by name via your mapping (even if the format XML remains unsuitable as a dictionary source).