...

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

1. It was decided to have not more than one virtual meeting per week
2. As the size of the team is reasonable small it was decided to allow for ad-hoc meetings via Skype
3. Terminology decision: "Testbed" is the thing as a whole, "Testbed Controller" is the software to be created
4. Development is done in the name of OpenPEPPOL
5. Hosting is done by a 3rd party company appointed by OO. The hosting solution must be able to run Docker images.
6. Controlling/administration of the created software is done by OO
7. OpenPEPPOL Operations should have a possibility to view the logfiles of the hosted solution
8. It must be able to easily and automatically access the logfiles of the Backbone solutions

Action items

1. -

...

1. -

Action items

1. -

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
  • Return values:
    • None
• 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
• 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
  • Return values:

*Distinguish the software as “Testbed controller”

...

1. Testbed Controller covers listed test cases and operates with a minimum of manual intervention
2. Ability to verify compliance on a technical level in terms of the PEPPOL AS2 profile
3. Ability to verify compliance on a technical level in terms of the PEPPOL AS4 profile
4. Ability to verify compliance on a technical level in terms of the E-SENS AS4 profile
5. 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.
6. Provide efficient and (best effort) scalable self-service Testbed on-boarding, for connectivity testing (not for Backbone AP integration)
   
7. The main purpose of the Testbed from the viewpoint of the tester: to support developers and operations with manual processes
8. The main purpose of the Testbed from the viewpoint of OpenPEPPOL: to check the maturity and verify the compliance of an onboarding entity
9. The Testbed Controller is controlled (managed, maintained, operated and supported) by OpenPEPPOL operations.
10. 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
11. 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.
    
12. 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.
13. Testbed Controller implementation strategy should cater for scalability in scope and functionality
14. 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

1. BIS document validation and content conformance
2. SMP server onboarding test (SMP client is in scope)
   
3. Local or regional requirements mandated by OpenPEPPOL Authorities.
4. Having a history of reports sent out (in scope for future Implementations)
5. Identify scenarios where a production certificate might make sense
6. Handle specific HTTP header values appropriate (Connection header, special status codes, ....)

Out of scope forever (until management decides different)

...