Getting started
Installing the module
Two models to deploy, one connection to fill in, and a check that proves it before a partner is involved.
What gets deployed
| Model | What it is | Do you need it |
|---|---|---|
| LunoLakeEDI | The module itself: partners, agreements, the flows, the tracker | Yes |
| LunoLakeEDIExample | A worked example of an added document type, in an invented format | Only while you are learning to extend |
The module is deployed the way any ISV solution is: the deployable package goes on through Lifecycle Services, and a database synchronise follows. It adds tables, so the synchronise is not optional.
Connecting to the service
One record, in EDI cloud connection. We give you the values; you enter them once per environment.
| Field | What it is |
|---|---|
| Customer ID | Which customer you are, on our side |
| Environment | Test or production, so a test document can never be sent to a real partner |
| API URL | Where the service listens |
| API key | The credential. Stored encrypted; it can be written and never read back |
Set the environment honestly. It is the guard that keeps a sandbox from posting live documents to your partners, and it is read on every transmission, not just at setup.
Proving it works, before a partner is involved
The connection form can send a test interchange. It goes to the service, is accepted or refused, and comes back with the answer. That single round trip proves four things at once: the URL is right, the key is right, the environment is right, and outbound traffic from your environment reaches us.
If it fails, the error says which of the four is wrong. A refused key and an unreachable host do not look alike.
The batch jobs
The work that is not tied to a posting runs as ordinary Dynamics batch jobs. They are safe to run more often than you think you need.
- Outbound processing. Hands queued documents to the service. Every few minutes is normal.
- Inbound processing. Takes delivery of what has arrived and reads it into staging. The receipts your inbound agreements have promised are sent from here, as part of handling the document that owes them, rather than by a job of their own.
- History. Draws the service’s record of what happened to each message back into the message log, so the log is complete rather than partial.
- Configuration. Publishes partner profiles, so the service can identify an arriving document before Dynamics has seen it.
Three more can be run on demand rather than on a schedule: importing the reporting configurations, importing a validation ruleset, and resetting a partner in a development or test environment.
Until these are running, documents sit in the queue looking as though something is wrong. Nothing is: they have simply not been picked up yet.
Security
The module ships four roles rather than leaving you to assemble them from duties.
- Administrator. Sets up partners, transports and agreements. Whoever owns the partner relationships.
- Operator. Works the daily queue, processes inbound documents, and fixes what is stuck.
- Partner link clerk. May add the link between a partner and a customer or vendor account, and nothing else. For the people who open accounts.
- Viewer. Can look and cannot change.
Give the viewer role freely. Being able to answer a customer without asking anyone is most of the value, and there is nothing in it that can be broken.
Then what
Setting up a real exchange is four records, in this order: your organisation, the partner, a transport, and an agreement per document per direction. The partner wizard walks the same path if you would rather be led.