عمليات استثناءات EDI وB2B
راجع حالة التكامل والإخفاقات عبر EDI وEDIFACT وcXML والملفات وواجهات API، ثم اربط الاستثناء بالسياق التشغيلي الذي يحتاجه فريق الدعم أو سلسلة التوريد.
A repeatable exception triage path that tells support or operations what failed, where it failed, who owns the next action, and what evidence is needed before retrying.
The job today
A support or supply-chain operator often checks monitors, run histories, partner feeds, translator or VAN status, logs, tickets, and business records just to determine whether an issue is a transport failure, mapping problem, missing document, stale feed, or actual business exception.
A useful first agent request
Review the recent DataSynch status, failed runs, and workspace activity for the authorized company/workspace. Summarize the failures that deserve attention, group repeated patterns when the evidence supports it, and identify the likely boundary to inspect next. Do not retry, resend, edit a mapping, or change a partner configuration.
Use this playbook when
- An EDI, EDIFACT, cXML, file, or API flow is missing, late, rejected, or failed and the team needs to determine whether the problem is transport, translation, mapping, data, or downstream processing.
- Support teams are reading logs manually without a consistent triage sequence.
- The business needs an exception summary that connects technical failure to a partner, document, order, shipment, or other operational record.
What you need
- A time window plus any known run ID, partner, document type, order number, shipment number, or other reference.
- Access to the authorized DataSynch workspace or the system that owns transport/translation if the failure occurred outside Atlasemoji.
- The expected business outcome: received, translated, normalized, delivered, acknowledged, or posted downstream.
What this should produce
- A failure classification: source/transport, translation, schema, mapping, business data, delivery, downstream, or unknown.
- The affected partner, run, document, or business reference when that evidence is available.
- A next-action recommendation with the owning system or team identified.
Operating playbook
- 1
Confirm what is actually missing
Start with the business expectation: which document, record, acknowledgment, or downstream update should exist? Do not start by searching every log in every system.
- 2
Check recent integration health
Review failed runs and workspace activity for the relevant time window. Determine whether the issue is isolated to one partner/document or part of a broader integration failure.
- 3
Locate the failure boundary
Identify the last successful boundary: partner transport, translator/VAN/iPaaS, Atlasemoji intake, normalization, mapping, outbound delivery, or downstream application.
- 4
Classify the exception
Separate syntax/schema failures from mapping problems, missing business values, partner identifiers, delivery failures, and downstream application errors. The classification determines the owner.
- 5
Preserve evidence before retrying
Capture the run reference, timestamps, partner/document identifiers, failure message, and relevant source/normalized values before any retry or manual correction occurs.
- 6
Fix in the owning system, then verify
Apply the correction through the approved production system or API. Then verify that the next run or retry reaches the expected business outcome. Current public MCP tools can diagnose and summarize; they should not perform the production retry.
Agent access for this playbook
Think of each MCP tool as a bounded API capability packaged for an agent: a defined operation, accepted inputs, approved tenant/resource scope, and returned result. The agent can reason across the tools it has been given, but the connection and underlying API authorization still determine what those tools can reach and do.
What the agent may inspect
- Authorized DataSynch workflow status and failed-run evidence exposed by current diagnostic tools.
- Authorized workspace activity useful for distinguishing an isolated failure from a repeated pattern.
- Additional partner or business context only when that context is actually available through the approved relationship.
What this Atlasemoji MCP tool set is not authorized to do
- The current public Atlasemoji MCP tool set is not authorized to resend EDI, change mappings, alter acknowledgments, restart connectors, or modify partner configuration.
- It cannot inspect a VAN, translator, mailbox, ERP, or partner system that has not been exposed through an approved Atlasemoji integration or capability.
Where a person stays in control
- A person confirms business impact and decides who owns the next action: partner, translator/VAN, source system, Atlasemoji integration, or downstream application.
- Retries, resubmissions, mapping changes, partner communication, and production fixes remain human- or policy-authorized actions.
How the data stays bounded
Give the agent only the company/workspace/manifest and diagnostic tools needed for the review. If a VAN, translator, mailbox, or partner system is not connected through an approved Atlasemoji capability, the agent should identify that evidence gap rather than imply it inspected that system.
Atlasemoji bounds agent access through the connection and the API-backed capabilities behind each tool. Issued credentials or API keys, tenant context, tool scope, resource identifiers such as workspace or manifest, permitted action, and environment all contribute to the authorization boundary. The agent works through the approved tool contract rather than receiving blanket platform access.
Read-only is the policy of the public Atlasemoji MCP tool set documented today, not a limitation of MCP itself. A customer or partner can separately approve additional API-backed tools with narrower or broader read, write, execution, or production scopes for a specific relationship.
Decision points
- No inbound record exists: investigate transport, partner delivery, or the translator/VAN/iPaaS before changing Atlasemoji mappings.
- Inbound exists but normalization fails: inspect schema, required fields, delimiters, field types, and partner-specific mappings.
- Normalization succeeds but outbound fails: inspect destination credentials, delivery configuration, downstream availability, and response errors.
- The same exception repeats across partners or documents: treat it as a shared integration defect, not a one-off partner problem.
Two access patterns, one Atlasemoji platform
Atlasemoji APIs are foundational in both patterns. A direct REST integration calls documented APIs from your application. An MCP integration lets an AI agent use selected Atlasemoji API and service capabilities through typed tools, with agent-oriented discovery, tool scoping, tenant/resource context, and policy controls around those calls.
Call Atlasemoji APIs directly from your code
Use the direct API path when your application already knows the exact operation it needs to perform. Your code authenticates, calls the documented endpoint, supplies the required company/workspace/manifest or object context, and receives the machine-readable result. This is ideal for repeatable, deterministic integration behavior.
Application / integration → API credential → Atlasemoji API → approved capability → resultLet an agent work through approved API-backed tools
Use MCP when the request is variable and benefits from an agent choosing among approved capabilities, comparing evidence, validating context, or explaining the next step. The agent calls MCP tools; Atlasemoji maps those tools to the underlying authorized API/service capabilities. The current public Atlasemoji tool set is intentionally read-only.
Person / AI agent → Atlasemoji MCP → approved tool → Atlasemoji API/service → approved capability → resultMCP is not a black box around the APIs
The MCP layer packages selected Atlasemoji API/service capabilities as tools an agent can discover and call. That lets Atlasemoji keep API credentials, tenant/resource boundaries, permitted actions, and audit context attached to the capability while giving the agent a simpler task-oriented interface. The tool may orchestrate one or more underlying calls, but it does not bypass the API and authorization model.
You can build both paths for the same business question and compare them. Useful measures include time to answer, manual searches removed, latency, successful-answer rate, escalation rate, cost per task, and how often a person needs to intervene. Many production designs will use both: direct APIs for deterministic automation and MCP for agent-led investigation, interpretation, and orchestration.
Direct REST/API production path
Keep the system of record where it already belongs. Atlasemoji can normalize, connect, validate, add geographic context, expose APIs, host integrations, and coordinate exceptions without forcing the entire process into one application.
- Use DataSynch status and developer APIs to expose run health, exception evidence, and approved operational controls available in your environment.
- Keep translation-specific remediation in the translator/VAN/iPaaS when that system owns the translation boundary.
- Use Intercept, webhooks, or downstream integrations for approved notifications and exception routing after the classification is reliable.
مسارات API والمساعدة ذات الصلة
These pages are not duplicates. Each one answers a different question in the build process: what route exists, how several routes work together, what a valid request looks like, or what a business capability is meant to do.
DataSynch API Explorer →
The searchable DataSynch API reference. Search by business job, route, schema, tag, object type, or app surface. Each route explains what it does, the context it requires, its related schema, the next logical route, and the full Swagger contract.
Search runs, exceptions, application-integration status, and dispatch. The run and exception routes help you distinguish a failed integration from a business event that arrived successfully.
DataSynch API Examples →
Known-good DataSynch request bodies. Use these after you know which route you need and want a concrete payload to compare with your own JSON, partner data, or integration test.
Use known-good request bodies when recreating a failed condition in a safe test path or checking whether an upstream payload shape differs from the expected contract.
DataSynch Developer Center →
The orientation page for DataSynch developers. Use it when you are not yet sure whether you need the API Explorer, Workbench, examples, quick starts, GCP guidance, or a direct/non-GCP integration path.
Use the Developer Center when the exception crosses multiple surfaces and you need to move from operations diagnosis into a specific API, Workbench, GCP, or direct-integration guide.
API & Integration Hub →
The API & Integration Hub is the architecture-level view of REST, OpenAPI, webhooks, Google Cloud, files, applications, EDI/EDIFACT/cXML, connectors, and partner workflows. Use it when deciding how Atlasemoji should connect to the systems you already have.
Use this to decide whether the owning boundary is a webhook, connector, EDI/EDIFACT/cXML flow, cloud integration, or customer application rather than treating every failure as a DataSynch mapping problem.
Agentic path through MCP and Atlasemoji APIs
Atlasemoji MCP is an agent-facing way to use selected Atlasemoji API and service capabilities through typed tools. The MCP server authenticates the connection, exposes the approved tool surface, and invokes the underlying capabilities with the permitted company, workspace, manifest, resource, and action context. Atlasemoji's current public tool set is read-only and non-destructive by design; that is a property of this tool set, not a limitation of MCP or APIs.
Connect this playbook to ChatGPT
Start by proving the playbook in one ChatGPT conversation. Connect Atlasemoji as a remote MCP app, verify the exact tools this playbook needs, and run the first request with authorized IDs. Remember what is happening underneath: ChatGPT calls the Atlasemoji MCP tool; Atlasemoji authorizes that tool and uses the corresponding API/service capability within the approved tenant and resource scope.
- 1
Get approved Atlasemoji MCP access
Obtain approved Atlasemoji MCP access and the company, workspace, or manifest identifiers you are authorized to use. Atlasemoji-issued credentials are part of the connection and authorization boundary; the endpoint alone does not grant tenant data access.
- 2
Open ChatGPT custom-app setup
On a supported ChatGPT web plan/workspace, enable Developer mode and open Settings → Apps → Create. Workspace administrators can also create the app from Workspace settings → Apps → Create. If those controls are not available, check the current OpenAI help page below or ask your workspace administrator.
- 3
Add the Atlasemoji remote MCP endpoint
Enter https://atlasemoji.com/api/mcp as the remote server endpoint. Atlasemoji documents Streamable HTTP transport and an Atlasemoji-issued bearer credential. Select the ChatGPT authentication option that matches the access method provided for your Atlasemoji relationship; Atlasemoji support can help if your workspace needs a different supported connection method.
- 4
Scan the tools and compare them with this playbook
Use ChatGPT's Scan Tools step, then compare the discovered tools with the list shown below. Each listed tool represents a bounded Atlasemoji capability with defined inputs and outputs; behind the MCP surface, Atlasemoji invokes the corresponding authorized API/service logic rather than giving the agent unrestricted platform access.
- 5
Run one real test in a new chat
Select the Atlasemoji draft app in a new ChatGPT conversation and paste the first test request below. Replace placeholder IDs with authorized values. Evaluate both the answer and the path used to get there: which tools were called, which tenant/resource context was used, and whether the evidence was sufficient.
- 6
Make the working pattern reusable
After the test works, make the pattern reusable if your ChatGPT workspace supports Workspace Agents. Add only the apps/tools needed for the job and choose the appropriate end-user or agent-owned connection model. You can also keep the workflow as a normal ChatGPT conversation or pair it with a direct REST integration.
https://atlasemoji.com/api/mcpTransport: Streamable HTTP. Authentication: Atlasemoji-issued bearer credential. MCP tools are backed by approved Atlasemoji API/service capabilities and remain bounded by the connection, tool scope, tenant/resource context, and permitted action.
get_datasynch_run_statusget_failed_runssummarize_workspace_activityReview the recent DataSynch status, failed runs, and workspace activity for the authorized company/workspace. Summarize the failures that deserve attention, group repeated patterns when the evidence supports it, and identify the likely boundary to inspect next. Do not retry, resend, edit a mapping, or change a partner configuration.
Current MCP tools used
get_datasynch_run_statusget_failed_runssummarize_workspace_activityTriage a failed integration window
Review failed DataSynch runs for the authorized workspace during the supplied time window. Group the failures by likely boundary or cause, identify repeated patterns, and summarize the evidence needed for the next action. Do not retry or change anything.
Explain one failed run
Review the supplied DataSynch run status and explain what completed, what failed, and what evidence points to the likely owning system or team. Keep the response operational and do not propose a write unless a separate approved capability exists.