Connect OpenText Trading Grid: EDI documents in and out

Create the connection in Integration under EDI connections, fill in the transport method, host, username and password or private key exactly as your OpenText onboarding pack gives them, test what the credential shape looks like, map each trading partner, and activate.

OpenText Trading Grid is an EDI platform: you exchange EDI documents with your trading partners through it — order documents come in from partners, and shipment and invoice documents go back out. This connection is not created in a channel wizard. You create it in Integration, under EDI connections, and every detail it asks for — host, username, and the rest — comes from the onboarding pack OpenText gives you when your account is opened. There is no other place to look those details up.

Prerequisites#

• An OpenText Trading Grid account, opened or being opened with OpenText. The connection details are issued as part of that account opening — they are not something you create or look up on your own.
• The onboarding pack from OpenText for your account. It carries the host, the username, and every other connection detail this guide asks you to fill in. Keep it at hand for the whole setup — if a detail is not in the pack, it is missing, and the fix is to ask your OpenText onboarding contact, not to guess it.
• A transport method, as stated in the onboarding pack: SFTP with a password, SFTP with a private key, or file drop. The pack decides which one your account uses — the three methods take different fields in the next steps, so know yours before you start filling in.
• At least one trading partner — a retailer or other partner — you will exchange EDI documents with through OpenText. Each partner is mapped separately later in this guide, using the partner and retailer identifiers agreed for that partner.

Get your credentials#

1. Go through account opening with OpenText. Your credentials are not created in a self-service portal and cannot be looked up elsewhere — they are issued to you as part of that onboarding.
2. Receive the onboarding pack for your account and find the SFTP host and the SFTP username in it. Copy both exactly as written — these values come from OpenText only, and a host or username from anywhere else will not belong to your account.
3. Find the secret that matches your transport method. If your pack says SFTP with a password, it gives you the SFTP password. If it says SFTP with a private key, it gives you the SFTP private key. If it says file drop, there is no password or private key to collect for this connection.
4. Keep the pack and the secret together, and treat the password or private key as a secret from the moment you receive it: store it somewhere safe, do not send it around in plain messages, and be ready to paste it once, in the next section. If anything the pack should contain is missing, ask your OpenText onboarding contact to complete it — do not fill the gap with a value from another account or another system.

Fill it into Integration#

1. Open Integration → EDI connections → New connection, and pick OpenText Trading Grid. OpenText has no channel wizard, so if you are looking for it in a channel or marketplace list, you are in the wrong place — the connection lives with the other EDI connections.
2. Transport method (transport_method): pick the one your onboarding pack states — sftp_password for SFTP with a password, sftp_key for SFTP with a private key, or file_drop for file drop. This choice decides which of the fields below are needed, so it has to match the pack, not whichever method looks easiest.
3. SFTP host (sftp_host): paste the host exactly as it appears in your onboarding pack. There is no standard host to type from memory — the pack is the only source for this value, so copy it rather than typing it, and if the pack shows no host, stop and ask your OpenText onboarding contact instead of guessing one.
4. SFTP username (sftp_username): paste the username from the same onboarding pack. It belongs with the host above — a username from a different account or a different system will not pair with it.
5. SFTP password (sftp_password): fill this in only when your transport method is sftp_password. Paste the password from the onboarding pack. It is stored encrypted and is never shown back after you save — if you later need to change it, you replace it with a new value rather than viewing the old one. For the other two methods, leave this field empty.
6. SFTP private key (sftp_private_key): fill this in only when your transport method is sftp_key. Paste the full private key from the onboarding pack, complete and unedited — a shortened or reformatted key is a different key. It is stored encrypted and is never shown back after you save. For the other two methods, leave this field empty. If your method is file_drop, neither secret field applies: what matters is that the transport method itself matches the pack.
7. Save the connection, but do not treat saving as the finish line. Test it next, then do the trading partner mapping — a connection with complete credentials but no partner mapping still cannot place any partner’s documents.

Test the connection#

Click Test connection, and read the result for what it actually covers. At this stage the check looks only at the shape of what you filled in: for the method you picked, is everything that method needs present — the transport method itself, the host and the username, the password for the password method, or the private key for the key method. If something that method needs is missing, the check fails and names the missing piece. If you picked file_drop, the check will report that the endpoint is still to be configured — with that method there is no server endpoint for the check to reach, so that result is expected and does not mean you filled anything in wrong. And whichever result you get, be clear about its scope: a complete credential shape is not proof that files can already move. Actually sending and receiving files is switched on together with the completion of your OpenText onboarding hookup, so judge this step only as a completeness check on the form, and use the FAQ below when a result surprises you.

Mapping / pick a template#

Mapping on OpenText is per trading partner, not one setting for the whole connection. For each partner, record the identifiers that partner is known by — the partner identifier and the retailer identifier agreed for that partner during onboarding and partner setup — and pick that partner’s template, so its incoming order documents are recognised as that partner’s and mapped into the standard order, and your shipment and invoice data is mapped back into the documents that partner expects. The identifiers are the point: a document that arrives carrying identifiers that match no mapping cannot be placed with the right partner, however complete the connection’s credentials are. Work through your partners one by one, and use the identifiers exactly as agreed for each — do not reuse one partner’s identifiers for another.

Activate#

Activate the connection once the form is complete and every trading partner you plan to start with is mapped. Activation puts the connection, with its transport method and its partner mappings, into service on the Integration side. Keep the scope of that in mind: actually sending and receiving files through OpenText is switched on together with the completion of your OpenText onboarding hookup, so if onboarding is not yet complete on that side, an activated connection will not carry files yet — that is the onboarding finishing, not a fault in what you filled in. Once file exchange is on, watch the first documents for each partner in Runs / Logs, partner by partner, before trusting the exchange unattended.

FAQ#

Test reports that the endpoint is still to be configured (file drop)

This is the expected result for the file drop method, not a sign that you filled something in wrong. With file drop there is no server endpoint for the check to reach, and the endpoint details that would come from onboarding are not configured as something the check can probe — so the check says so, plainly, instead of passing you.

Do not change the transport method or invent a host just to make the test look green. Keep the method the onboarding pack states, finish the trading partner mapping, and confirm with your OpenText onboarding contact where the account opening stands — sending and receiving files is switched on together with the completion of that onboarding hookup, and the first real documents are what you check in Runs / Logs.

Test fails: something the chosen method needs is missing

The fields on the form do not yet make a complete set for the transport method you picked. The usual cases are plain gaps: no host, no username, the password method chosen but the password field left empty, or the key method chosen but the private key field left empty. A mismatch counts too — for example, a private key pasted in while the method is still set to the password method, so the piece the check looks for is not there.

Compare the form against the onboarding pack, field by field: transport method first, then host, then username, then the one secret your method uses — the password for sftp_password, the private key for sftp_key, pasted in full. Fill only the missing or misplaced piece, save, and test again. If a value is missing from the pack itself, ask your OpenText onboarding contact for it rather than borrowing one from another account.

The credential shape looks complete, but no files move yet

Nothing on the form is necessarily wrong. The connection test only checks that the credential shape is complete for the method you picked — it does not by itself set up file transfer. Actually sending and receiving files is switched on together with the completion of your OpenText onboarding hookup, so a form that checks out completely can still sit before that switch: the connection is ready on this side, and the file exchange has not been turned on yet.

Confirm with your OpenText onboarding contact whether the onboarding hookup for your account is complete — that completion is what turns file exchange on. Meanwhile finish the trading partner mapping, so nothing on this side is still missing when it is. After the hookup is complete, check the first documents for each partner in Runs / Logs; if files still do not move after onboarding is confirmed complete, take the connection details and the partner identifiers back to that same check against the onboarding pack.

A partner’s documents do not land, or land with the wrong partner

The connection can be complete while one partner’s mapping is not. Mapping is per partner, and documents are placed by the identifiers they carry — the partner identifier and the retailer identifier agreed for that partner. If the identifiers recorded in that partner’s mapping do not match the ones its documents carry, the documents have no correct home: they either do not land at all, or they are read as another partner’s whose identifiers they happen to match.

Open that partner’s mapping and compare its recorded partner and retailer identifiers, character by character, with the identifiers agreed for that partner in the onboarding and partner setup. Correct the mapping — never the other partners’ mappings — save it, and check that partner’s next document in Runs / Logs. A partner you add later needs the same treatment before its first document: its own identifiers, its own template, checked on its own.