e-SENS Y4 e-Delivery Task Force.Documentation
Date March 2017
e-SENS Y4 e-Delivery Task Force.Documentation
1
Contents
Date March 2017 .......................................................................................................................... 1
Mandate & Mission Statement for the AS4 Taskforce, based on mutual agreement between eSENS
and EC-CEF. .................................................................................................................................. 5
Introduction ................................................................................................................................. 6
Synopsis of the test approach and method.................................................................................... 6
Interoperability Test Process ............................................................................................................... 7
Technical documentation on the participating AS4 gateways and setup. ........................................ 8
Flame FMS AS4: ................................................................................................................................... 8
Holodeck B2B:...................................................................................................................................... 8
IBM-B2B:.............................................................................................................................................. 9
Domibus:.............................................................................................................................................. 9
EESSI: AS4.NET v1.0.0 .......................................................................................................................... 9
RSSBUS:................................................................................................................................................ 9
Minder and Kerkovi setup ................................................................................................................. 10
Starting status and documentation on fixes and changes during the test on each participating AS4
gateway. .................................................................................................................................... 10
Flame FMS AS4: ................................................................................................................................. 10
Holodeck B2B:.................................................................................................................................... 10
IBM-B2B:............................................................................................................................................ 11
Domibus:............................................................................................................................................ 11
EESSI: AS4.NET ................................................................................................................................... 12
RSSBUS:.............................................................................................................................................. 12
Results from the testing – a consolidated test schema, with specifics from each gateway as an
option. ....................................................................................................................................... 13
Consolidated test results: .................................................................................................................. 13
Flame FMS AS4: ................................................................................................................................. 13
Holodeck B2B:.................................................................................................................................... 14
IBM-B2B:............................................................................................................................................ 14
Domibus:............................................................................................................................................ 14
EESSI: AS4.NET ................................................................................................................................... 14
RSSBUS:.............................................................................................................................................. 14
Conclusions and recommandations based on the testing. ............................................................ 15
Recommendations for eSENS AS4 profile and suggestions for future work: ..................................... 15
For the profile .................................................................................................................................... 15
For the implementation of AccessPoints. .......................................................................................... 15
For test platform................................................................................................................................ 15
Future activities. ................................................................................................................................ 15
Test scenario setup´s and descriptions: ....................................................................................... 16
Submit Message PartyInfo and Collaboration Settings ..................................................................... 16
Submit Message Properties ............................................................................................................... 17
Submit Part Properties ...................................................................................................................... 19
Sample Submit Message ................................................................................................................... 19
Gateway Common P-Mode Configuration Settings .......................................................................... 21
Interop Tests ...................................................................................................................................... 22
Generic AS4 interop testing ............................................................................................................... 31
Large volume and payload testing .................................................................................................... 31
e-SENS Y4 e-Delivery Task Force.Documentation
2
Artifacts ............................................................................................................................................. 31
Glossary ............................................................................................................................................. 33
References ......................................................................................................................................... 33
Backup from old document – clean up later. ............................................................................... 34
P-Mode Parameters Used (e-SENS AS4 profile) ............................................................................ 34
e-SENS Y4 e-Delivery Task Force.Documentation
3
Document Reviewers
Name
David Hixon
Henrik Carlsen
Theo Kramer
Muhammet Yildiz
Maarten Daniels
Sander Fieten
Gregor thomas
Toon vanhoutte
Frederik Gheysels
Christian Vindinge Rasmussen
Role
Participant – IBM , B2B gateway
Participant – IBM , B2B gateway
Participant – Flame Computing (FCE)
Conformance Test Representative
Participant – CEF, Domibus
Participant – Holodeck B2B
Particitant – eSENS WP1
Participant – EESSI – AS4.NET
Participant – EESSI , AS4.NET
eSENS WP6 WP Leader
Niels Pagh-Rasmussen
Participant – IBM , B2B gateway
Document History
Revision
Draft1
Draft 2
Date
06 March 2017
15 March 2017
Description
Document creation
Document update based on input from all
participants
e-SENS Y4 e-Delivery Task Force.Documentation
Modified by
Niels Pagh
Niels Pagh
4
Mandate & Mission Statement for the AS4 Taskforce,
based on mutual agreement between eSENS and ECCEF.
The mission of the e-SENS Y4 e-Delivery Task Force will be to review and continue the work done in
2015 and 2016 within the e-Delivery AS4 interoperability Workgroup, working towards the vision of
robust, production-ready e-Delivery infrastructure in as many domains as possible and with as many
solutions as possible. The e-Delivery Task Force shall complement the activities in the “e-Delivery
group” chaired by the EC. A close collaboration between the Task Force and the EC is foreseen.
The main objectives and activities will be to:
a. Work together on specific technical issues that ensure the suitability and maturity of AS4based eDelivery solutions, integrated with other ABBs required for operations in particular
domains.
b. Continue the testing already done in e-SENS on aspects like large files, multiple files,
interoperability of different implementations on Java and .net, etc. A testing plan will be
produced at the beginning outlining the activities of the period February 2017 – April 2017.
c. Document test, setup and outline outstanding issues.
The activity and testing plan must consider how to address the points below:
1. Focus around the replication of previous testing including new providers.
2. With the exception of new vendors, we should not repeat testing already done in the 2015
WG or in the eInvoicing pilot
3. Search for the .NET implementation and engage the vendor/implementer for cross-platform
testing
4. Provide guidance to vendors how to integrate TL access to their solutions and test before
March 2017
5. Compare requirements from different domains on Trust, Discovery, Capability and
Configuration, following the request from eJustice and working towards a standardized
multi-domain solution
6. Work with WP6 & the test team for Interoperability Testing (as presented in Edinburgh)
For these purposes, weekly Tcons and a F2F workshop will be held. Work will be aligned with the
priorities and developments within the CEF eDelivery DSI and business communities. The Task Force
will be open to all AS4 vendors and implementers either working already with e-SENS or willing to
engage.
From an e-SENS perspective, both WP5 (pilots) and WP6 (BBs) will be involved. WP6 lead and
operate the TF. Niels Pagh, IBM is appointed as coordinator and will together with Christian
Rasmussen and Cagatay Karabat ensure alignment with other project activities.
The taskforce participants are: Flame, Chasquis , IBM, RSSBUS, Domibus, EESSI AS4.NET,
Minder/Kerkovi and WP6.
Kich off TCON Thuesday 24th January 2017.
e-SENS Y4 e-Delivery Task Force.Documentation
5
One workshop In Brussels 6-7th March2017 has been held.
This document, based on the contributions of all the participants, documents and summarizes the
results of the work and testing and provides recommendations
Introduction
Participation in the Taskforce activities was open to any vendor or organization that wanted to
participate, though as it was a test with limited resources and timeframe we did not attempt to enlist
as many vendors as possible. The scope for the activities was giving in general in the mandate paper,
mentioned in the first section above.
Furthermore the Taskforce has been asked to extend and add the scope for the test to align to
already stated visions and target for the basic eDelivery transport infrastructure, as it is stated by ECCEF, eSENS and the LoU between OpenPEPPOL and EC-CEF.
Each participating organization provided one part time person on a best effort basis to perform their
part of the interoperability test. IBM provided David Hixon (Technical Lead IBM B2B Advanced
Communications Gateway), Axway provided Vivek Chauhan (Architect, Axway B2Bi), Flame
Computing provided Theo Kramer, Chasquis Consulting provided Sander Fieten, and the German
government provided Stefan Müller.
The work in the Taskforce is planned to follow some timeframes. Each timeframe end with a short
report documenting the work, technical specifications and test results and findings, including
conclusions and recommendation to further work.
Each timeframe will be based on a certain amount of funding to cover cost for the involved parties.
The funding for the first phase is coming from eSENS, WP6. Funding for further phases will be
decided by EC-CEF.
Ownership of the taskforce is in the first phase eSENS, WP6. Owner ship for further phases is
expected to be EC-CEF.



First timeframe is from kick-off end of January 2017 until eSENS project close down.
Second timeframe is expected to be 2 -3 month until end June 2017.
Third and further timeframes are not yet decided.
Synopsis of the test approach and method
This sections describes the testing framework, test process, details of trigger messages, processing
mode configuration requirements for the systems under test (SUT) and message requirements for
completing the CEF/e-SENS AS4 interoperability test exercise.
For details see the last section with Test scenario setup´s and descriptions:
Interoperability (interop) testing closely follows the testing framework of the Minder/Kerkovi (M-K)
conformance testing framework. The main differences being that M-K does not act as an interceptor
e-SENS Y4 e-Delivery Task Force.Documentation
6
and the remote SUT MSH being a separate and different e-SENS compliant AS4 Gateway Message
Handler (MSH).
Interop tests are triggered by submit messages from the M-K testing framework, acting as corner 1
(C1) in a 4 corner model, on a receiving SUT MSH. The receiving SUT MSH must then construct a
message in accordance to the submit message property details and send this message to a receiving
SUT MSH.
The receiving SUT MSH must, on successful receipt of a message, respond with a receipt to the
sending SUT MSH and forward the message to corner 4 (M-K).
Interoperability Test Process
The test process follows the following basic procedure
1.
2.
3.
4.
Review the interop test documentation.
Configure SUT MSH.
Register endpoints with M-K and interop partners.
Proceed with tests where the tests are triggered by M-K acting either as C1 or C4.
e-SENS Y4 e-Delivery Task Force.Documentation
7
Technical documentation on the participating AS4
gateways and setup.
Each participating gateway gives a short description on technical setup – following the template
below.
Setup:




Software – technology / standard product
Customization :
Hardware
Other:
Common setup:



p-mode
Address interchange
Other….
Flame FMS AS4:
Product: FMS AS4 Version 5.4
Platform



Operating System - Ubuntu 12.04
Java – 1.8
FMS AS4 Standalone Server configured as flame-c2 and flame-c3 listening on separate
interfaces
Hardware


CPU: 2 x Intel Virtual CPU 64Bit 1.6GHz
Memory: 8GByte
Holodeck B2B:
Product version: 2.1.2 with specific back-end connector for the communication with the Minder
testbed.
Platform: Amazon Linux, OpenJDK Java Runtime version 1.7
Hardware: The regular interop tests were run on an Amazon t2.medium instance which has 4 GB of
memory and flexibly assigns CPU based on workload, but with a maximum of 2 CPU cores.
e-SENS Y4 e-Delivery Task Force.Documentation
8
For the size and volume test an Amazon t2.xlarge instance was used. This instance has 16GB of
memory and a maximum of 4 CPU cores.
IBM-B2B:
Product version: IBM B2B Advanced Communications Gateway B2Bac Adapter 1.0.0.5
Software platform: Java 7
Application server: WebSphere Application Server 8.5.5.2 – Liberty Profile
Database: IBM DB2 Version 10.5
Operating System: CentOS 7.0 - Minimal Install (64 bit)
Hardware: SoftLayer Cloud Server, Computing Instance: 1 2.0 GHz Core, 16 GB RAM, 100GB HDU
Domibus:
Product version: Domibus 3.2.2
Software platform: Java 8
Application server: Tomcat
Database: MySQL
Operating System: RedHat 7.2
Hardware: Azure VM Standard D3 v2 (4 cores, 14 GB memory) running both domibus-c2 and
domibus-c3 instances. Each instances gets max 4 GB memory allocated.
EESSI: AS4.NET v1.0.0
Technical documentation




Software – technology / standard product: EESSI AS4.NET v1.0.0
Customization: Minder Submit / Deliver / Notify connector (same as conformance testing)
Hardware:
7 GB Memory
2.20 GHz CPU
Other: Hosted in Microsoft Azure Cloud, Windows Server 2016.
RSSBUS:
Product: RSSBus Connect 16.0.6277.0
e-SENS Y4 e-Delivery Task Force.Documentation
9
Platform: .NET
Server: IIS/Embedded Web server
Operating Sytem: Windows 2008 Server R2
Hardware: Windows VM (4 GB RAM, 1 core)
Minder and Kerkovi setup .
Muhammet – I suggest that you come with a short overview/description of the Minder and Kerkovi
setup.
Starting status and documentation on fixes and
changes during the test on each participating AS4
gateway.
Each participating gateway gives a short description on the starting status in relation to
interoperability etc and documentation on fixes and changes made during the test.
Flame FMS AS4:
The Flame FMS AS4 configuration was adapted from the e-SENS Conformance testing configurations.
The following p-modes were created based on the CEF e-SENS Configuration Document



oneWaySend
o Service : SRV_SIMPLE_ONEWAY
o Action : ACT_SIMPLE_ONEWAY
twoWaySend
o Service : SRV_SIMPLE_TWOWAY
o Action : ACT_SIMPLE_TWOWAY
oneWaySendSize
o Service : SRV_SIMPLE_ONEWAY_SIZE
o Action : ACT_SIMPLE_ONEWAY_SIZE
No changes were required to the core FMS AS4 product during the interop test exercise. The FMS
server was restarted with additional memory allocated to the Java Virtual Machine for the large
payload test.
Holodeck B2B:
At the start of the interop test event the Holodeck B2B gateway was configured only for testing the
One-Way scenario. The tests could be successfully executed between Holodeck B2B and Flame,
Domibus and AS4.net.
e-SENS Y4 e-Delivery Task Force.Documentation
10
The test with RSSbus could not be completed before the test event due to configuration issues both
in Minder and RSSbus. This was however quickly solved during the event.
To enable a successful exchange between the Holodeck B2B and IBM-B2B gateways a patch was
applied to the Holodeck B2B security library to add some extra elements to the header of the
message. These headers are required for successful processing by the IBM-B2B gateway but are
however not mandated by the specifications. Because of a firewall issue the exchange from the IBMB2B to Holodeck B2B gateway could not be tested.
At the end of the event also configuration of the Two-Way scenarios was added to the configuration
of the Holodeck B2B and successfully tested with all other gateways with exception of the IBM-B2B.
IBM-B2B:
When starting the interoperability test F2F event, IBM was able to receive successfully from most of
the other participants, but for outbound messages we were facing a firewall issue. This was due to
recent security upgrades combined with system cloning to create a new and separate environment
for AS4 interop testing. A workaround was implemented at the workshop that allowed outbound
test cases to work. The underlying problem was eventually fixed and IBM removed the workaround.
The one-way interoperability test cases to AS4.Net and RSSBus were successful in both directions.
The outbound one-way test cases to Holodeck and Flame were also successful. The inbound oneway test cases from Holodeck originally failed, because HolodeckB2B did not include a <KeyInfo>
element in the second <EncryptedData> element and the IBM software expected there to be one.
HolodeckB2B had included a <DataReference> tag in the <EncryptedKey> element obviating the need
for the <KeyInfo> element in the <EncryptedData> and the standards list the <KeyInfo> element as
optional, so it appears that HolodeckB2B’s semantics are technically valid. Because of this, IBM has
created a defect on the IBM B2B Advanced Communications product and will correct the behavior.
So that we could continue the test, HolodeckB2B implemented a change to send <KeyInfo> elements
in all <EncryptedData> elements and the inbound test case was successfully executed.
For Flame, the outbound one-way interoperability test case worked. Unfortunately, the one-way
inbound test case had the exact same problem as Holodeck had and therefore failed.
For Domibus, the one-way inbound test case was successful. However, the workaround for the
outbound test case was implemented too late in the workshop for Domibus, as they had already
shutdown before the test case could be executed with the workaround. Consequently, the outbound
test case to Domibus was not successful at the workshop. Subsequent attempts after the workshop
have failed as well, though the cause is unknown at this time. They returned an HTTP 500 Internal
Error to IBM and that has been reported to them and they are investigating.
Domibus:
When starting the interoperability test F2F event, Domibus could already successfully send messages
to and from all other participants except the following exclusions:
e-SENS Y4 e-Delivery Task Force.Documentation
11



To IBM: This was caused by the fact that Domibus did not sign the empty body of the AS4
message. All other implementations where tolerant accepting this, but IBM was strict and
(correctly) rejected the message. This issue was solved by updating the security policy
settings in Domibus (no code change needed).
From IBM: This was caused by a firewall issue at IBM side.
To RSSBus: RSSBus was expecting the PartyId type="urn:oasis:names:tc:ebcore:partyidtype:unregistered" to be set in the exchange between Domibus and RSSBus while in these
tests this attribute was not required. This was solved by an update to the PMode settings of
RSSBus.
EESSI: AS4.NET
Fixes / Issue encountered

Configuration issues
Solution: Correct the PMode configuration

Flame cannot decrypt a message from AS4.NET.
Solution: Update AS4.NET to start the Id in the DataReference-list with a #

Flame does not accept the X509IssuerSerial key reference
Solution: Use BinarySecurityToken or KeyIdentifier. It's on the backlog of Flame

AS4.NET cannot verify signature of Flame
Solution: still work-in-progress, probably related to canonicalization and white space
differences between JAVA and .NET.

RSSBus cannot process Non-Repudiation Information of AS4.NET
Solution: Bug on AS4.NET side, as there was double base64 encoding
RSSBUS:
•
•
•
•
•
To Flame: RSSBus was adding both BinarySecurityToken elements at the top of
the XML section instead of ordering the BST elements just above the relevant
section where they were being used.
From Flame: RSSBus was expecting a KeyInfo section in the EncryptedData
section, but as it turns out this is optional and should not be required.
From Holodeck: In two-way communication, RSSBus was not including some of
the message properties that were expected. Other implementations did not fail it
seems, but Holodeck requested these message properties to be included.
From Domibus: The PartyId was not properly being included in the message
properties when sending to Domibus.
From IBM: Firewall issues caused this problem and were not resolved.
e-SENS Y4 e-Delivery Task Force.Documentation
12
Results from the testing – a consolidated test
schema, with specifics from each gateway as an
option.
Consolidated test results:
Test results are documented in the attached Excel and can be found online on these two links:
https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?spaceKey=EDELCOMMUNITY&title=Test
+Planning&focusedCommentId=40054672&refresh=1489136876346#comment-40054672
Optional – specifics from each participating gateway.
Consolidated test results and schema.
One way testing
Two way testing
Flame FMS AS4:
Tests oneWaySend, twoWaySend and oneWaySendSize using compression, signing and encryption
test status is follows



AS4.Net
o oneWay Send – Fail due to SOAP Envelope formatting
o oneWay Receive – Success
o twoWay Send – Fail
o twoWay Receive – Success
o Large Payload Send – not tested
o Large Payload Receive – not tested
Domibus
o oneWay Send – Success
o oneWay Receive – Success
o twoWay Send – Success
o twoWay Receive – Success
o Large Payload Send – not tested
o Large Payload Receive – not tested
Holodeck B2B
o oneWay Send – Success
o oneWay Receive – Success
o twoWay Send – Success
e-SENS Y4 e-Delivery Task Force.Documentation
13
o twoWay Receive – Success
o Large Payload Send – not tested
o Large Payload Receive (500MBytes) – Additional JVM memory required - Success
IBM-B2B
o oneWay Send – Fail due to Firewal
o oneWay Receive – Success
o twoWay Send – Fail due to Firewall
o twoWay Receive – Partial Success
o Large Payload Send – not tested
o Large Payload Receive – not tested
RSSBUS
o oneWay Send – Success
o oneWay Receive – Success
o twoWay Send – Success
o twoWay Receive – Success
o Large Payload Send – not tested
o Large Payload Receive – not tested


Holodeck B2B:
In an exchange with the Flame gateway a 500MB payload was successfully exchanged. Although the
exchange took almost 2 hours due to the limited bandwidth available both gateways handled the
large payload without problem.
IBM-B2B:
Domibus:
In addition to the interoperability testing, the Domibus Access Points were successful in sending a 1.9
GB from domibus-c2 to domibus-c3. However since Domibus 3.2.2 has a size limit of 999 MB for
attachments, for these tests a non-released development version was being used that was installed
on 2 separate more powerful Azure VMs.
EESSI: AS4.NET
Results


Can be found in the overall matrix
All successful, except:
o Not able to receive messages from IBM, because of firewall issues at IBM side
o Not able to verify signature of Flame (see issue above)
RSSBUS:
e-SENS Y4 e-Delivery Task Force.Documentation
14
Conclusions and recommandations based on the
testing.
Recommendations for eSENS AS4 profile and suggestions for future
work:
General recommendations:
Recommendations

Provide advice and guidance and the key reference method to use
For the profile
For the implementation of AccessPoints.
For test platform.
Future activities.
e-SENS Y4 e-Delivery Task Force.Documentation
15
Test scenario setup´s and descriptions:
Submit Message PartyInfo and Collaboration Settings
M-K triggers each test by sending a submit message to the SUT. The submit message takes the form
of the conformance testing submit messages. Details of the PartyInfo and Collaboration settings are
as follows. Note the difference in from.Role and CollaborationInfo.Service.
from.PartyId is set to
<ns2:PartyId>minder</ns2:Role>
from.Role is set to
<ns2:Role>http://www.esens.eu/as4/interoptest/testdriver</ns2:Role>
to.PartyId is set to the party identity of the sending SUT. Eg.
<ns2:PartyId>senderParty-c2</ns2:Role>
to.Role is set to
<ns2:Role>http://www.esens.eu/as4/interoptest/sut</ns2:Role>
CollaborationInfo.Service is set to
<ns2:Service>http://www.esens.eu/as4/interoptest</ns2:Service>
CollaborationInfo.Action is set to
<ns2:Action>Submit</ns2:Action>
e-SENS Y4 e-Delivery Task Force.Documentation
16
Submit Message Properties
The Submit message properties define the test requirements and must be replicated in the messages
any message from a sending SUT to a receiving SUT. These properties are as follows
e-SENS Y4 e-Delivery Task Force.Documentation
17
MessageProperty MessageId must be used for the sending gateway
UserMessage.MessageInfo.MessageIsd. Eg.
<ns2:Property name="MessageId">abc-123</ns2:Property>
MessageProperty ConversationId must be used for the sending gateway
UserMessage.Collaboration.ConversationId. It is used to keep track of interop test
message conversations by M-K. Eg.
<ns2:Property name="ConversationId">xyz-321</ns2:Property>
MessageProperty TA_id may be used to identify the test being run. One of
· <ns2:Property name="TA_id">InteropOnewaySignonly</ns2:Property>
· <ns2:Property name="TA_id">InteropOneway</ns2:Property>
· <ns2:Property name="TA_id">InteropTwoway</ns2:Property>
MessageProperty FromPartyId is set to the gateway sending party. Eg.
<ns2:Property name="FromPartyId">senderParty-c2</ns2:Property>
MessageProperty FromPartyRole is set to the gateway sending party role. It will
always be set to the following
<ns2:Property name="FromPartyRole"> http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/ns/core/200704/initiator</ns2:Property>
MessageProperty ToPartyId is set to the gateway receiving party. Eg.
<ns2:Property name="ToPartyId">receiverParty-c3</ns2:Property>
MessageProperty ToPartyRole is set to the gateway receiving party role. It will
always be set to the following
<ns2:Property name="ToPartyRole"> http://docs.oasis-open.org/ebxmlmsg/ebms/v3.0/ns/core/200704/responder</ns2:Property>
MessageProperty Service is set to the interop service identifier and may be used
for identifying the sending p-mode. One of
· <ns2:Property name="Service">SRV_ ONEWAY_SIGNONLY</ns2:Property>
· <ns2:Property name="Service">SRV_SIMPLE_ONEWAY</ns2:Property>
· <ns2:Property name="Service">SRV_SIMPLE_TWOWAY</ns2:Property>
MessageProperty Action is set to the interop Action identifier and may be used
for identifying the sending p-mode. One of
· <ns2:Property name="Action">ACT_ONEWAY_SIGNONLY</ns2:Property>
· <ns2:Property name="Action">ACT_SIMPLE_ONEWAY</ns2:Property>
· <ns2:Property name="Action">ACT_SIMPLE_TWOWAY</ns2:Property>
MessageProperty originalSender is set to the original sender on the sending
outer corner.
<ns2:Property name="originalSender">urn:oasis:names:tc:ebcore:partyidtype:unregistered:C1</ns2:Property>
MessageProperty finalRecipient is set to the final receiver on the receiving outer
e-SENS
Y4 e-Delivery Task Force.Documentation
corner..
18
Submit Part Properties
The Submit part properties provide details of the payloads to be included in the message to be
constructed on the sending SUT MSH.
Sample Submit Message
A sample Submit message from C1 to C2 triggering a simple oneWay interop test between two
different parties is as follows
e-SENS Y4 e-Delivery Task Force.Documentation
19
e-SENS Y4 e-Delivery Task Force.Documentation
20
Gateway Common P-Mode Configuration Settings
Several common p-mode settings are used for sending and receiving gateway SUTs. These p-mode
settings are as listed below
PMode Parameter
Value/Setting
Notes
PMode.ID
Not used
PMode.
Not used
Agreement
PMode.MEP
PMode.




MEPbinding
PMode.Initiator.
oneWay
twoWay
One way tests
push
pushAndPush
One way tests
Party identifier
Party
PMode.Initiator.
Two way tests
Two way tests
May be unknown on the
receiving SUT for some
e-Delivery use cases.
Default
Role
PMode.Responder.
Party identifier
Party
PMode.Responder.
Default
Role
PMode[1].
BusinessInfo.



SRV_ ONEWAY_SIGNONLY
SRV_SIMPLE_ONEWAY
SRV_SIMPLE_TWOWAY
Service
e-SENS Y4 e-Delivery Task Force.Documentation
21
PMode[1].
BusinessInfo.



ACT_ONEWAY_SIGNONLY
ACT_SIMPLE_ONEWAY
ACT_SIMPLE_TWOWAY
Action
PMode[1].Protocol.Ad
dress PMode[1].Protocol.SO
APVersion Set to the SUT http[s]
address. Each SUT must
provide their endpoint
address to the
participants in the tests.
SOAP 1.2
Payloads are typically
not included in the
SOAP body.
PMode[1].Security.X5
09.Sign
See Interop Tests below
PMode[1].Security.
X509.Encryption
See Interop Tests below
PMode[1].Security.Se
ndReceipt
True
NRR Response Receipt
Interop Tests
Interop tests determine the inter MSH product interoperability between e-SENS AS4 compliant
products of different vendors. It is assumed that any product vendor participating in the interop
exercise has successfully completed the CEF e-SENS conformance testing exercise.
The tests are geared towards the general interoperability of successfully sending and receiving
messages. The tests do not in any way indicate suitability of an AS4 product in a production
environment where factors such as integrating with different business systems come into play.
e-SENS Y4 e-Delivery Task Force.Documentation
22
1. Connectivity - M-K to SUT
Purpose - to determine that M-K can connect to the SUT
oneWay message - non SWA payload (M-K to C2)
2. General AS4 and e-SENS interop tests
Purpose - to determine if gateway products from different vendors can successfully send and
receive messages conformant to the requirements of e-SENS.
2.1. C2 (product A) to C3 (product B) oneWay signed - triggered by
M-K on C1
MessageProperty TA_id: b InteropOnewaySignonly
MessageProperty Service: SRV_ONEWAY_SIGNONLY
MessageProperty Action: ACT_ONEWAY_SIGNONLY
Endpoint: C3 endpoint. To be provided by C3 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided
 Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
 Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: No
Service: SRV_ONEWAY_SIGNONLY
Action: ACT_ONEWAY_SIGNONLY
Payloads: Provided by M-K
2.2. C3 (product B) to C2 (product A) oneWay signed - triggered by
M-K on C4
MessageProperty TA_id: InteropOnewaySignOnly
MessageProperty Service: SRV_ONEWAY_SIGNONLY
MessageProperty Action: ACT_ONEWAY_SIGNONLY
Endpoint: C3 endpoint. To be provided by C3 party
MEP: One way - push
e-SENS Y4 e-Delivery Task Force.Documentation
23
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided
 Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
 Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: No
Service: SRV_ONEWAY_SIGNONLY
Action: ACT_ONEWAY_SIGNONLY
Payloads: Provided by M-K
2.3. C2 (product A) to C3 (product B) oneWay signed and encrypted - triggered by M-K on C1
MessageProperty TA_id: InteropOneway
MessageProperty Service: SRV_SIMPLE_ONEWAY
MessageProperty Action: ACT_SIMPLE_ONEWAY
Endpoint: C3 endpoint. To be provided by C3 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_ONEWAY
Action: ACT_SIMPLE_ONEWAY
e-SENS Y4 e-Delivery Task Force.Documentation
24
Payloads: Provided by M-K
2.4. C3 (product B) to C2 (product A) oneWay signed and encrypted - triggered by M-K on C4
MessageProperty TA_id: InteropOneway
MessageProperty Service: SRV_SIMPLE_ONEWAY
MessageProperty Action: ACT_SIMPLE_ONEWAY
Endpoint: C2 endpoint. To be provided by C2 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_ONEWAY
Action: ACT_SIMPLE_ONEWAY
Payloads: Provided by M-K
2.5. C2 (product A) to C3 (product B) to C2 (product A) twoWay signed and encrypted - triggered
by M-K on C1 and C4.
MessageProperty TA_id: InteropTwoway
MessageProperty Service: SRV_SIMPLE_TWOWAY
MessageProperty Action: ACT_SIMPLE_TWOWAY
e-SENS Y4 e-Delivery Task Force.Documentation
25
Endpoints: C3 endpoint. To be provided by C3 party. C2 endpoint. To be provided by
C2 party
MEP: twoWay - pushAndPush
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_TWOWAY
Action: ACT_SIMPLE_TWOWAY
Payloads: Provided by M-K
2.6. C3 (product B) to C2 (product A) to C3 (product B) twoWay signed and encrypted - triggered
by M-K on C4 and C1
MessageProperty TA_id: InteropTwoway
MessageProperty Service: SRV_SIMPLE_TWOWAY
MessageProperty Action: ACT_SIMPLE_TWOWAY
Endpoints: C2 endpoint. To be provided by C2 party. C3 endpoint. To be provided by
C3 party
MEP: towWay - pushAndPush
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided

Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
e-SENS Y4 e-Delivery Task Force.Documentation
26

Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_TWOWAY
Action: ACT_SIMPLE_TWOWAY
Payloads: Provided by M-K
3. Volume Testing
These tests provide an indication of the ability of a particular e-SENS compliant MSH to handle a
particular volume of messages containing payloads of fixed sizes for both sending and receiving
within a given time frame.
The tests are not geared to benchmarking systems but rather to ensure that a gateway is capable
of handling a reasonable volume of messages of various sizes as required by the various e-SENS
initiatives.
Benchmarking is an exercise that is typically handled by operators of gateways when selecting a
particular gateway product.
3.1. C2 (product A) to C3 (product B) oneWay signed and encrypted with increasing number of
messages of a 10KB payload - triggered by M-K on C1
MessageProperty TA_id: <to be determined>
MessageProperty Service: SRV_SIMPLE_ONEWAY_VOLUME
MessageProperty Action: ACT_SIMPLE_ONEWAY_VOLUME
MessageProperty Volume: one of 100, 250, 500, 1000
Endpoint: C3 endpoint. To be provided by C3 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided
e-SENS Y4 e-Delivery Task Force.Documentation
27


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_ONEWAY
Action: ACT_SIMPLE_ONEWAY
Payloads: Provided upfront.
3.2. C3 (product B) to C2 (product A) oneWay signed and encrypted with increasing number of
messages of a 10KB payload - triggered by M-K on C4
MessageProperty TA_id: <to be determined>
MessageProperty Service: SRV_SIMPLE_ONEWAY_VOLUME
MessageProperty Action: ACT_SIMPLE_ONEWAY_VOLUME
MessageProperty Volume: one of 100, 250, 500, 1000
Endpoint: C2 endpoint. To be provided by C2 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_ONEWAY
Action: ACT_SIMPLE_ONEWAY
e-SENS Y4 e-Delivery Task Force.Documentation
28
Payloads: Provided upfront.
4. Payload Size Testing
These tests provide an indication of the ability of a particular e-SENS compliant MSH to handle
messages containing payloads of different sizes for both sending and receiving within a given
time frame.
The tests provide an indication of the ability of an MSH to handle messages of different payload
sizes.
4.1. C2 (product A) to C3 (product B) oneWay signed and encrypted with increasing payload size
- triggered by M-K on C1.
MessageProperty TA_id: <to be determined>
MessageProperty Service: SRV_SIMPLE_ONEWAY_SIZE
MessageProperty Action: ACT_SIMPLE_ONEWAY_SIZE
MessageProperty Volume: one of 64MB, 128MB, 256MB, 512MB, 1GB, 1.9GB.
Endpoint: C3 endpoint. To be provided by C3 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_ONEWAY_SIZE
Action: ACT_SIMPLE_ONEWAY_SIZE
Payloads: Provided upfront.
Notification from C2 to M-K - time taken and hash of payload sent.
e-SENS Y4 e-Delivery Task Force.Documentation
29
Notification from C3 to M-K - hash of payload received.
4.2. C3 (product B) to C2 (product A) oneWay signed and encrypted with increasing payload size
- triggered by M-K on C4.
MessageProperty TA_id: <to be determined>
MessageProperty Service: SRV_SIMPLE_ONEWAY_SIZE
MessageProperty Action: ACT_SIMPLE_ONEWAY_SIZE
MessageProperty Volume: one of 64MB, 128MB, 256MB, 512MB, 1GB, 1.9GB.
Endpoint: C2 endpoint. To be provided by C2 party
MEP: One way - push
Compress: Yes - gzip
Retry: None
Sign: Yes – keyreference type to be decided


Signature HashFunction: http://www.w3.org/2001/04/xmlenc#sha256
Signature Algorithm: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Encrypt: Yes – keyreference type to be decided


Data Encryption Algorithm: http://www.w3.org/2009/xmlenc11#aes128-gcm
Key Encryption Method algorithm: http://www.w3.org/2009/xmlenc11#rsaoaep
Service: SRV_SIMPLE_ONEWAY
Action: ACT_SIMPLE_ONEWAY
Payloads: Provided upfront.
Notification from C3 to M-K - time taken and hash of payload sent.
Notification from C2 to M-K - hash of payload received.
5. Other test scenarios
These test scenario use cases may include other e-Delivery use cases and other AS4 messaging
use cases as used in the EU region. The list of use cases is not complete and where each use case
may have specific requirements including SML/SMP lookups, unknown initiating partners on the
e-SENS Y4 e-Delivery Task Force.Documentation
30
receiving end, various keyreference methods for signatures and encryption, etc. These test
scenario use cases may need to be covered separately.
5.1. e-Tendering
5.2. e-Procurement
5.3. e-Invoicing
5.4. e-Health
5.5. e-Justice
5.6. PEPPOL
5.7. ENTSOG
5.8. Etc.
Generic AS4 interop testing
Beside simple interop test by exchanging a message the following cases can also be tested in the
interop:




Use of AS4 compression with text, XML and binary payloads
Use of http chunking and compression
Use of e-SENS recommended values for key encryption
Use of different key reference methods when signing
o Should include at least BST reference
o Preferably with inclusion of cert chain

Large volume and payload testing


Increasing number of messages with a 10KB payload:
o 100
o 250
o 500
o 1000
o 2000
Increasing payload size:
o 32MB
o 128MB
o 256MB
o 512MB
o 768MB
o 1GB
o 1.5GB
o 2GB (-8bytes)
Artifacts
Details on partners, keystores, endpoints etc are available at
https://ec.europa.eu/cefdigital/wiki/display/EDELCOMMUNITY/Test+Planning
e-SENS Y4 e-Delivery Task Force.Documentation
31
e-SENS Y4 e-Delivery Task Force.Documentation
32
Glossary
This section contains a list of abbreviations used throughout the document
Cn (where n = 1 to 4) - corner n in the 4 corner model
M-K - Minder/Kerkovi acting as test controller and test verifier
SUT- System under test. One of C2 and C3
SMP - Service Metadata Publishing
SML - Service Metadata Lookup
PEPPOL - Pan-European Public Procurement Online
ENTSOG - European Network of Transmission System Operators for Gas.
e-SENS - Electronic Simple European Networked Services
CEF - Connecting Europe Facility
SWA - SOAP with Attachments profile. https://www.w3.org/TR/2000/NOTE-SOAP-attachments20001211 and http://docs.oasis- open.org/wss-m/wss/v1.1.1/os/wss-SwAProfile-v1.1.1-os.html
References
e-SENS AS4 Profile Version 1.11
http://wiki.ds.unipi.gr/display/ESENS/PR+-+AS4+-+1.11
OASIS AS4 Profile of ebMS 3.0 Version 1.0 Committee Specification 03
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/cs03/AS4-profile-v1.0cs03.odt
Minder/Kerkovi Documentation
https://mindertestbed.org:15000/#
Interop Test Description - Sander Fieten
"interop test description_v2.docx"
e-SENS Y4 e-Delivery Task Force.Documentation
33
Backup from old document – clean up later.
P-Mode Parameters Used (e-SENS AS4 profile)
The set of PModes used in the interoperability test were as follows. This is a reformatted version of
the original table provided by Pim van der Eijk.
P-Mode Parameters
Support
required?
“MUST”
“ALLOWED”
Value
Value
General P-Mode parameters
PMode.ID
Y
PMode.Agreement
Y
PMode.MEP
Y
(no special
constraint for
the Value)
(Must be a URI)
 http://www.oa
sisopen.org/com
mittees/ebxml
-msg/one-way
 http://www.oa
sisopen.org/com
mittees/ebxml
-msg/two-way
PMode.MEPbinding:
Y
PMode.Initiator.Party
Y
(no special
constraint for
the Value)
PMode.Initiator.Role
Y
(no special
constraint for
the Value)
PMode.Initiator.
N
 http://www.oasisopen.org/committees/e
bxml-msg/push
Authorization.username
P-Mode.Initiator.
Authorization.password
PMode.Responder.Party
e-SENS Y4 e-Delivery Task Force.Documentation
Y
(no special
constraint for
34
the Value)
PMode.Responder.Role
Y
PMode.Responder.
N
(no special
constraint for
the Value)
Authorization.username
P-Mode.Responder.
Authorization.password:
PMode[1].Protocol
PMode[1].Protocol.Address
PMode[1].Protocol.SOAPVersion
Y
(Must be URL: http 1.1
protocol)
Y
 1.2
Y
 http://docs.oasisopen.org/ebxmlmsg/ebms/v3.0/ns/core
/200704/service
(if for test service)
 http://docs.oasisopen.org/ebxmlmsg/ebms/v3.0/ns/core
/200704/test
(if for test service)
PMode[1].BusinessInfo
PMode[1].
BusinessInfo.Service
PMode[1].
Y
BusinessInfo.Action
PMode[1].
Y
(no special
constraint for
the Value)
Y
(A list of
properties)
BusinessInfo.MPC
PMode[1].BusinessInfo.
Properties[]
PMode[1].BusinessInfo.
Y
PayloadProfile[]
PMode[1].BusinessInfo.
N
PayloadProfile.maxSize
PMode[1].ErrorHandling
PMode[1].ErrorHandling.
N
(Must not be set)
Y
 True
Report.SenderErrorsTo
PMode[1].ErrorHandling.
e-SENS Y4 e-Delivery Task Force.Documentation
35
Report.AsResponse
PMode[1].ErrorHandling.
Y
 True(preferred
)
Y
 True
Report.ProcessErrorNotifyConsumer
PMode[1].
ErrorHandling.Report.ProcessError
NotifyProducer
PMode[1].
 False
Y
 True
ErrorHandling.Report.DeliveryFailu
resNotifyProducer
 False
Y
 True
PMode[1].ReceptionAwareness
Y
 True
PMode[1].ReceptionAwareness.Retry
Y
 True
PMode[1].ReceptionAwareness.Duplica
teDetection
Y
 True
PMode[1].Security
PMode[1].Security.WSSVersion
Y
 1.1
PMode[1].Security.X509.Sign
Y
PMode[1].Security.X509.
Y
(Value must match the
certificate of the sender)
Y
 http://www.w3.org/20
01/04/xmlenc#sha256
Y
 http://www.w3.org/20
01/04/xmldsigmore#rsa-sha256
PMode[1].
ErrorHandling.Report.MissingReceip
tNotifyProducer
PMode[1].Reliability
Signature.Certificate
PMode[1].Security.X509.
Signature.HashFunction
PMode[1].Security.X509.
Signature.Algorithm
PMode[1].Security.
e-SENS Y4 e-Delivery Task Force.Documentation
Y
(A list of the
names of XML
elements that
should be
signed)
(A list of the
36
X509.Encryption.Encrypt
names of XML
elements that
should be
encrypted)
Y
(Value must match the
certificate of the
receiver)
Y
 http://www.w3.org/20
09/xmlenc11#aes128gcm
PMode[1].Security.SendReceipt
Y
 True
PMode[1].Security.SendReceipt.Non
Repudiation
Y
 True
PMode[1].Security.SendReceipt.Reply
Pattern
Y
 Response
PMode[1].Security.X509.
N
PMode[1].Security.
X509.Encryption.Certificate
PMode[1].Security.
X509.Encryption.Algorithm
Encryption.MinimumStrength
PMode[1].Security.
N
UsernameToken.username.
PMode[1].Security.
N
UsernameToken.password
PMode[1].Security.
N
UsernameToken.Digest
PMode[1].Security.
N
UsernameToken.Nonce
PMode[1].Security.
N
UsernameToken.Created
PMode[1].Security.
N
P-ModeAuthorize
e-SENS Y4 e-Delivery Task Force.Documentation
37