...
Aksamit, Mikael <mikael@aksamit.se>Collanus, Risto <risto.collanus@visma.com>
Johannes Hunderi
Helger, Philip <philip.helger@brz.gv.at>
Langøy, Bård <bard.langoy@pagero.com>
Fabio Vigna
Jacob Lund Mogensen
Even Østvold
Edmund Gray
Siarhei Baidun
Agenda
Topics not discussed
...
Information item
Decisions
- It was decided to have not more than one virtual meeting per week
- As the size of the team is reasonable small it was decided to allow for ad-hoc meetings via Skype
- Terminology decision: "Testbed" is the thing as a whole, "Testbed Controller" is the software to be created
- Development is done in the name of OpenPEPPOL
- Hosting is done by a 3rd party company appointed by OO. The hosting solution must be able to run Docker images.
- Controlling/administration of the created software is done by OO
- OpenPEPPOL Operations should have a possibility to view the logfiles of the hosted solution
- It must be able to easily and automatically access the logfiles of the Backbone solutions
Action items
- -
...
- -
Action items
- -
Subject of discussion
Rest API
Supported actions
AS2
- TB AP sends a transaction to a system under test (SUT)
- Prerequisites:
- SUT URL and AP certificate must be user provided
- SUT must be automatically registered in a (new) TB SMP with special ID, using the Proxy AP URL and the SUT AP certificate
- DNS timing must be considered
- Proxy AP must find the correct URL from the Orchestration layer based on SBDH Instance ID; it must than proxy the binary stream "as is" to SUT AP URL
- Input params:
- SBDH - XML binary serialized (xs:base64binary)
- Document Type ID
- Process ID
- Sending Participant Identifier
- Receiver Participant Identifier (SUT participant ID)
- Transmission Instance ID (Orchestration layer provided)
- Payload
- SBDH - XML binary serialized (xs:base64binary)
- Return values:
- None
- Prerequisites:
- TB AP send return value for transmission back to Orchestration Layer
- Input Params:
- Original MDN as byte[]
- REM or some other generic XML format
- Return values:
- None
- Input Params:
- TB AP receives a transaction from a SUT AP.
- Prerequisite:
- Every TB AP must be registered in an SMP with its own ID, using the Proxy AP URL and the TB AP certificate
- Each TB AP gets its own certificate
- Each test transmission targets exactly one TB AP (and not all in parallel)
- Each SUT AP must perform an SMP client lookup with the TB AP participant ID
- Received AS2 message (byte[]) including the AS2 headers - should be recorded by Proxy AP (to Orchestration layer)
- Input params:
- SBDH values for matching with the recorded values (see prerequisites)
- Document Type ID
- Process ID
- Sending Participant Identifier
- Receiver Participant Identifier
- Transmission Instance ID
- SBDH values for matching with the recorded values (see prerequisites)
- Return values:
- Prerequisite:
*Distinguish the software as “Testbed controller”
...
- Testbed Controller covers listed test cases and operates with a minimum of manual intervention
- Ability to verify compliance on a technical level in terms of the PEPPOL AS2 profile
- Ability to verify compliance on a technical level in terms of the PEPPOL AS4 profile
- Ability to verify compliance on a technical level in terms of the E-SENS AS4 profile
- Implemented as a web-based application with a self-service user interface. Self-identification based on PEPPOL test certificate based on PKI v3 is foreseen. Not open to everyone.
- Provide efficient and (best effort) scalable self-service Testbed on-boarding, for connectivity testing (not for Backbone AP integration)
- The main purpose of the Testbed from the viewpoint of the tester: to support developers and operations with manual processes
- The main purpose of the Testbed from the viewpoint of OpenPEPPOL: to check the maturity and verify the compliance of an onboarding entity
- The Testbed Controller is controlled (managed, maintained, operated and supported) by OpenPEPPOL operations.
- The Testbed Controller is being hosted by a 3rd party in a generic setup (provider) and implemented in a way to ensure minimal maintenance activities. SLA is mandatory between 3rd party host and OpenPEPPOL
- The Testbed should enable the usage of different PEPPOL compliant AP implementations (like Oxalis, ph-as2 ...) as Backbone APs. The same implementation can be available in different versions.
- The Testbed should produce a report with the result of executed test cases and which Backbone AP implementations were tested. It should be possible to assert the authenticity of the report.
- Testbed Controller implementation strategy should cater for scalability in scope and functionality
- A bullshit AP (naming (c) Anna-Lis) implementation must be created that sends out crappy documents without validation (for the negative tests)
Out of scope for version 1.0, in scope for a later version
- BIS document validation and content conformance
- SMP server onboarding test (SMP client is in scope)
- Local or regional requirements mandated by OpenPEPPOL Authorities.
- Having a history of reports sent out (in scope for future Implementations)
- Identify scenarios where a production certificate might make sense
- Handle specific HTTP header values appropriate (Connection header, special status codes, ....)
Out of scope forever (until management decides different)
...