Skip to content

What Should Second-Level Support Check Before Opening a Ticket?

This page is for OEM partners' centralized second-level support teams, the MIMB and MetaKarta experts who handle escalations before they reach Meta Integration. It covers the four-step escalation path (documentation, MIMB log analysis, the Customer Support Knowledge Base, and the Customer Issue Tracking System), the rules of engagement in your OEM agreement, patch policy, and the environment details to collect. After reading it, you can file a ticket with the logs, source metadata, and reproduction steps it needs.

Get started

Frequently asked questions

Can OEM customers contact Meta Integration support directly?

Under the OEM agreement, partners ask their customers to contact the partner's first-level support. Partners then route MITI product issues to a small centralized team of MITI software experts, their second-level support, which is the team that works with Meta Integration.

See the OEM rules of engagement.

What must first-level support check before escalating?

Ten checks: read the log's errors and warnings, review the bridge documentation and tooltips, apply the current cumulative patch, verify access rights, run a full harvest after a version change, and request every input file. Then request proof of valid sources, get source files in native format, restore and test database backups, and try to reproduce the issue in house.

See the first-level support obligations.

What information does a new support ticket need?

The project (OEM.Vendor.Tool), type, priority, and a summary that explains acronyms and names the customer or prospect. Add the import and export bridge specifications with tool versions, full debug logs, source metadata, screenshots or videos, step-by-step reproduction instructions, and the affected and fix versions.

See the new ticket requirements.

How do I compare two MIMB harvest logs?

Use the MIMB-LogAnalyzer utility to compare the two logs. It checks seven kinds of difference: full versus incremental scope, single versus multi-model mode, bridge parameters such as dev versus prod URLs and filters, CPU and memory resources, source metadata dates, patch-level dates of the bridge libraries, and bridge specification versions.

See MIMB log analysis.

Can a patch upgrade a customer to a new version?

Patches work only within a given version (10.1.0, for example). They're cumulative, so each one includes every earlier fix, and they exclude Apache Tomcat and PostgreSQL updates as well as partner-specific customization and configuration files. MIMB patches ship weekly and platform patches monthly, with limited patches for older versions.

See the patch policy.

What environment information should I collect for a ticket?

Application and database server information from MANAGE > System, shared metadata repository content and configuration statistics, performance test results, server details from MANAGE > Servers, and database maintenance execution logs. Large deployments should add configuration statistics. Attach these to the ticket so support sees the same environment the customer runs.

See customer environment information.

How do I sign in to the knowledge base and issue tracker?

Both use your assigned Google account ending in @metaintegration.info. Add it as a separate Chrome profile, then open the Customer Support Knowledge Base on its Google Shared Drive, or sign in to the Customer Issue Tracking System on Cloud JIRA with Continue with Google.

See the Google login steps.

Return to the MetaKarta documentation home. For supported tools and known bridge limits, see the MIMB bridge documentation; for current patches by version, see Releases & Roadmap.