registered, you can run against it.
See what can run
Run everything
module and you get every advertised protocol-conformance suite your plan covers for the
connection’s OCPI version. Scenarios are never part of a sweep, for any account: name one to
run it.
Direct Payment and Bookings are both on the Automate plan, so against a real endpoint their
suites run only for accounts that have it. Against the sandbox they are open to everyone, because it costs us nothing
to let you see what they do before you buy. When a run leaves them out, the report says which
modules were withheld, so a smaller total is never a mystery.
?wait=<seconds> blocks for up to that long, to a maximum of 55; larger values are
clamped to it, so a script asking for 120 gets 55 and should loop rather than wait longer. Four outcomes, and a CI script has to
tell them apart:
Read
data.status before you read the counters. A 200 alone does not mean there is a
verdict to read, and jq answers null for a summary that is not there, which shell
arithmetic turns into an error rather than a number. The script below checks the status first
for exactly this reason.
Poll GET /api/v1/testing/runs/$REPORT_ID?wait=<seconds> until the run reaches a terminal
state. Without ?wait, the start call returns immediately and you poll the same way.
Repeat a run
A run creates objects on your endpoint, and the ids it uses are derived from a seed. Send the same seed again and the run sends the same requests, down to the object ids, which is what turns “it failed yesterday” into something you can put in front of a partner.seed is optional and is 1 to 128 characters. Omit it and one is generated for you; either way
the seed comes back in data.seed on every answer the start call gives, so keep it with the
report. What it reproduces is the requests we send, not your endpoint: replaying a seed
against a target that already holds those objects re-sends ids it created the first time, and an
immutable object such as a settled CDR will rightly refuse the second POST.
The seed on a Charging Journey is a different field with the same name. It belongs to the
journey manifest, it shapes the scenario itself rather than object ids, and it is set when you
compile the plan. See Run a charging journey.
Run one module or scenario
Send one manual OCPI command
Before scripting a whole flow, it is often worth firing a single request and reading the exact exchange:
The response includes the request that was sent, the response status and body, and the
latency.
Manage your runs
404.
Gate your build on it
1 means “your partner broke a rule”. Exit 2 means “we did not get an answer”.
Those are different problems and a build log should not conflate them, and an ungraded run
belongs in the second group: it says nothing about your partner.
Gate on failed, not on warnings. A warning means a recommendation was declined, and
a declined recommendation breaks no rule. If you fail your build on warnings you will be
fixing code that already works, which is the exact mistake this tool refuses to make on
your behalf. See Read your report.
A packaged GitHub Action that runs this script with the same exit codes is built but not
published yet. Until it is, use the script above.
Store the key as a repository or organisation secret so the runner masks it. See
Create an API key.