B2B 통합 테스트
제한된 샘플 데이터, 스키마 탐지, 매핑 준비, API 및 격리 환경을 사용해 프로덕션 전에 B2B 워크플로를 검증합니다. 문서 변환은 기존 변환기, VAN, iPaaS 또는 고객 소유 서비스에 남겨둘 수 있습니다.
A repeatable B2B test case with representative documents, expected outcomes, negative cases, trace evidence, and a clear production promotion boundary.
The job today
B2B testing usually means assembling representative documents, checking envelopes and identifiers, reviewing mappings, running a conversation, tracing acknowledgments and downstream results, and deliberately testing failure cases before production access is allowed.
A useful first agent request
Inspect this representative B2B sample for the authorized test. Detect its schema, preview normalized rows, validate the manifest or sample contract, and identify mapping assumptions or missing required values that should be resolved before the test scenario runs. Do not promote configuration or use production credentials.
Use this playbook when
- A new or changed B2B flow needs to be proven before a partner or customer is put into production.
- A mapping, document version, transport change, or downstream integration could break an existing trading-partner flow.
- You need evidence that both normal and failure cases behave as expected, not just one successful sample.
What you need
- The document flow or business conversation to test, such as an order-to-ship-to-invoice sequence.
- Representative source documents or synthetic test documents with stable identifiers.
- Expected normalized values, downstream outcomes, acknowledgments, or validation results.
- At least one negative or edge case that should fail in a known way.
What this should produce
- A reusable test scenario or suite with expected outcomes.
- Traceable evidence for successful and failed documents.
- A production-readiness decision that separates mapping/data issues from transport or downstream issues.
Operating playbook
- 1
Define the business conversation
Describe the sequence you are proving, not just an individual file. For example, an X12 flow might test 850 purchase order, 856 ship notice, and 810 invoice behavior together.
- 2
Build representative test data
Use stable test identifiers and enough item, location, quantity, date, and partner variation to exercise the mapping. Keep production customer data out of the test unless explicitly approved.
- 3
Validate structure and mapping first
Detect schema, preview normalized rows, validate the manifest or sample contract, and review proposed mappings before running a larger scenario. This catches cheap failures early.
- 4
Run the happy path
Execute the approved test-network or integration test path and confirm each expected document, normalization result, acknowledgment, and downstream handoff.
- 5
Run negative cases on purpose
Test missing identifiers, invalid values, malformed structure, mapping exceptions, or delivery failures that matter to the business. Confirm that the failure is visible and understandable.
- 6
Promote the tested contract, not the test harness
Use the approved production integration and credential process after the scenario is accepted. Keep synthetic data, test endpoints, and MCP analysis separate from production execution.
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
- Representative sample structure, bounded row previews, proposed mappings, and manifest/schema validation supplied to current tools.
- Test evidence returned by enabled Atlasemoji applications or APIs when that evidence is part of the approved environment.
- The documented boundary between Atlasemoji and an existing translator, VAN, iPaaS, or customer-owned integration.
What this Atlasemoji MCP tool set is not authorized to do
- The current public Atlasemoji MCP tool set is not authorized to promote mappings, enable production credentials, or execute irreversible production writes.
- It should not be represented as executing Atlas Circuit test runs unless that specific capability has been separately exposed and approved.
Where a person stays in control
- A person defines the expected business result and the negative cases that matter—not just whether transport returned a green status.
- A person approves acceptance and the transition from test authority to production credentials, routes, mappings, and writes.
How the data stays bounded
Use synthetic or approved representative data, a test manifest/workspace where applicable, and preparation/validation tools. Current public MCP helps prepare and inspect the test; execution of Atlas Circuit or another test workflow remains in the enabled API/application path rather than being implied as a public MCP capability.
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
- If schema or mapping is still ambiguous, stop before end-to-end testing and resolve the contract first.
- If document translation happens in a VAN, translator, iPaaS, or customer system, include that boundary in the test evidence without moving it into Atlasemoji.
- If the happy path passes but negative cases are invisible, the integration is not operationally ready.
- If a test needs production credentials or irreversible writes, replace that step with an isolated test or explicit production approval.
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 Atlas Circuit/B2B test-network or DataSynch test interfaces for repeatable scenarios, suites, document traces, and integration proving where those capabilities are enabled.
- Use the Workbench and API Explorer to inspect schemas, mappings, sample payloads, and developer contracts before production promotion.
- Keep document translation in the existing translator/VAN/iPaaS when appropriate; test the boundary and outputs rather than duplicating the translator.
- Promote only the mappings, routes, and configurations that passed the agreed scenario and negative cases.
관련 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 receiver, normalize, XREF, master tables, and runs. These route families let you define the intake, normalization, identifier resolution, expected result, and trace evidence for a test.
DataSynch Workbench →
A guided build surface for seeing how DataSynch routes work together. It includes workflows for imports, XREF, geofences, telemetry, dispatch, and run logs so you can understand the sequence before wiring it into your own application.
Use guided workflows to exercise the sequence with test data before introducing production credentials or downstream writes.
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 bodies as the baseline for positive and negative test cases so a failure can be attributed to the test condition rather than malformed scaffolding.
EDI, EDIFACT & cXML →
The EDI, EDIFACT & cXML solution connects B2B document flows, testing, diagnosis, and integration choices. Use it to decide which part belongs in Atlasemoji and which part should remain in an existing translator, VAN, iPaaS, or partner system.
Use this to define the B2B conversation you are proving—documents, translation boundary, acknowledgements, validation, and partner expectations—before testing individual API calls.
MCP documentation →
The current Atlasemoji MCP contract: remote endpoint, Streamable HTTP transport, authentication model, tool names, required scopes, tenant requirements, example inputs, representative outputs, and expected errors.
Use the MCP contract to see exactly which read-only preparation and validation tools can support the test and what scopes or tenant context each tool requires.
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.
detect_file_schemapreview_datasynch_rowssuggest_field_mappingvalidate_manifest_schemaInspect this representative B2B sample for the authorized test. Detect its schema, preview normalized rows, validate the manifest or sample contract, and identify mapping assumptions or missing required values that should be resolved before the test scenario runs. Do not promote configuration or use production credentials.
Current MCP tools used
detect_file_schemapreview_datasynch_rowssuggest_field_mappingvalidate_manifest_schemaPrepare a B2B sample for testing
Inspect the supplied B2B sample, detect its schema, preview the normalized rows, validate the manifest contract, and identify mapping ambiguities that should be resolved before the test scenario runs.
Review a proposed mapping before a suite runs
Review the proposed source-to-target mapping for the test sample. Identify missing required values, risky assumptions, and fields that should be included in a negative test. Do not promote or write the mapping.