RNE PCSTAF/TAP-TSI Testing Framework
RailNetEuropeOelzeltgasse 3/8AT-1030 Vienna
Phone: +43 1 907 62 72 00Fax: +43 1 907 62 72 90
Version Description Author
0.1 Initial Seid Maglajlic
PCS 2018 – TAF/TAP TSI Testing Framework
Content1 About this document...................................................................................................................32 Setting up the test case with Common Interface........................................................................3
2.1 Testing with SoapUI.............................................................................................................52.1.1 Path Coordination Message.........................................................................................5
2.1.2 Path Request Message..............................................................................................102.1.3 Receipt Confirmation Message..................................................................................11
2.1.4 Path Details Message.................................................................................................123 Conclusion................................................................................................................................18
4 References................................................................................................................................20
2
PCS 2018 – TAF/TAP TSI Testing Framework
1 About this documentThis document serves for easier testing of the TAF / TAP compliant connection to PCS. These tests are aimed to help the development of the TAF/TAP compliant connection from domestic systems to RNE PCS (Path Coordination System).
Tools
The tool SoapUI is used to send XML messages as a web service call to Common Interface. The SoapUI is the precondition for the testing described in this document.
Systems
PCS: basic knowledge of PCS is required
Common Interface: basic knowledge of Common Interface (CI) is required
2 Setting up the test case with Common InterfaceThe tests are composed oft sending/receiving PathCoordinationMessage, PathRequestMessage, PathDetailsMessage and PathConfirmedMessage via PCS between the test partners.
Configuration of Common Interface communication is necessary for this test case. As long as your company is not having the Common Interface communication configured with RNE PCS Test Environment Common Interface, we use “local loop” in Common Interface at RNE. For more information on Common Interface configuration, please refer to CCS Common Interface documentation.
In this document we use the guiding example of CD Cargo (CD-C), SZDC, RailCargo Austria (RCA) and ÖBB-Infrastruktur. In all the screenshots, the company codes of these Rus and IMs will be used:
- 2154 for CD-C (LeadRU)- 0054 for SZDC (Coordinating IM)- 2181 for RCA- 0081 for ÖBB-Infra
For the test case of 2 RUs – 2 IMs as this one, the routing configuration has to be provided in Common Interface for inbound and outbound communication between the test partners:
(1) CD-C (2154, outbound) -> SZDC (0054, inbound)
- Path Request Message- Receipt Confirmation Message- Path Confirmed Message
(2) SZDC (0054, outbound) -> CD-C (2154, inbound)
- Path Details Message- Receipt Confirmation Message
3
PCS 2018 – TAF/TAP TSI Testing Framework
(3) CD-C (2154, outbound) -> RCA (2181, inbound)
- Path Coordination Message- Receipt Confirmation Message
(4) RCA (2181, outbound) -> CD-C (2154, inbound)
- Path Coordination Message- Receipt Confirmation Message
(5) RCA (2181, outbound) -> ÖBB-I (0081, inbound)
- Path Request Message- Receipt Confirmation Message- Path Confirmed Message
(6) ÖBB-I (0081, outbound) -> RCA (2181, inbound)
- Path Details Message- Receipt Confirmation Message
(7) SZDC (0054, outbound) -> ÖBB-I (0081, inbound)
- Path Coordination Message- Receipt Confirmation Message
(8) ÖBB-I (0081, outbound) -> SZDC (0054, inbound)
- Path Coordination Message- Receipt Confirmation Message
The “local loop” configuration can be seen in the Common Interface of RNE (https://taftest1.railneteurope.info/LI/). The figures 1 and 2 are covering the case (1) listed above.
Figure 1 Outbound configuration for CD-C of the “Remote LI”. Note the localhost IP address 127.0.0.1 for “local loop”
4
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 2 Inbound configuration for SZDC
Figure 3 local loop for web services for inbound (receiving) for both CD-C from SZDC and from RCA
In the same way, the local loop on Common Interface of RNE is configured for other test partners. In the real case, the IP addresses of the test partners Common Interfaces will be used, instead of 127.0.0.1. The rest of the CI configuration applies also if the “Remote LI”-s are really remote. Here we use the “local loop” just for the simplicity of the testing.
2.1 Testing with SoapUI
2.1.1 Path Coordination Message
Firstly, the outbound web service communication channel between participating Rus must be established.
Figure 4 outbound web service for Path Coordination Message from CD-C to RCA.
Important: Please note the WSDL URL -> this is the Web Service Endpoint of the Common Interface! This is the address (the end point) that has to be used in SoapUI testing tool.
Some general organizational rules apply:- The company that wants to use CI as the interface to PCS has to contact RNE and
establish the test plan as a test partner
5
PCS 2018 – TAF/TAP TSI Testing Framework
- Together with the test partner, the dossier in PCS will be initially established to be used in examples.
- The same dossier will be prepared in the PathCoordinationMessage for dossier creation (type of information = 30)
We have here an example in SoapUI.
Figure 5 The SoapUI example project contains the 15 web service calls for PCS interaction
6
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 6 with Path Coordination Message a dossier will be created in PCS. Important: Type of Information = 30
NOTE: the web service end point has to be set accordingly for the web service call.
Figure 7 web service end point indication in SoapUI - mandatory! Check the Figure 4.
After execution of the first web service call:
- Check the Common Interface Outbound Connector service overview and logs.- Check in the PCS Test System in TAF/TAP TSI test environment of RNE if the dossier was
created accordingly- If the dossier was created successfully – note the dossier id in the PCS. It will be needed
for further test execution. It will be placed in the core element of the Case Reference ID.
7
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 8 If any further operation is executed, the PCS dossier id has to be placed in the core element of the Case Reference ID. Note also the web service end point for RU-RU communication has to be used
Additionally, the receipt confirmation is generated by PCS and “sent back” to the Leading RU that was creating the dossier, in order to keep the track on the identifiers. Also there is the Case Reference ID already set. If Path Request ID was not provided in the first web service call with Path Coordination Message, the PCS will generate the Path Request ID, which will be provided in the Receipt Confirmation Message. For the call given in the figure 6, the Receipt Confirmation looks as follows.
8
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 9 Receipt Confirmation after the first web service call conatins the Case Reference ID and Path Request ID which has to be used for the further calls
Note: the core element of the PR ID, if generated by PCS, can be found in PCS as the PCS specific “path id” of the RU (main) timetable. The Path Request ID will have for both participating Rus the same core element, but the different company code. Hence, it will be unique. The RU may also specify the own Path Request ID instead of generated one – PCS will store it and link it to the RU timetable.
In the further RU-RU communication, the update and harmonization of dossier with PathCoordinationMessage (use TrainID and Case Reference ID for dossier identification) is used.
For example, the Path Coordination Message is used to set the acceptance indicator of PCS to green by “accepting the dossier harmonization” code for the element “Type of Information.
9
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 10 harmonization accepted - PCS dossier gets the green light from the RU.
2.1.2 Path Request Message
The precondition of the successful execution of the Path Request message via PCS is that the dossier is fully harmonized in PCS. For this purpose, the calls of web services with Path Coordination message with “Type of Information = 2” is necessary, to set the PCS dossier RU-lights to green.
Figure 11 Path Request message web service call has to be done on the different web service end point (the one for CD-C and SZDC)
Important: when using PCS in the TAF / TAP compliant framework, it is sufficient that the LeadRU issues the Path Request. The PCS will generate the Path Request messages on behalf of the involved RUs and send them to the corresponding IMs.
10
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 12 Path Request: identifiers and Type of Information
In the Path Request message, the Type of information is set to 4 (“harmonization completed”). The identifiers TrainID, Path Request ID and, when communicating via PCS, Case Reference ID are necessary. The best practice with SoapUI examples is to copy these identifiers from the second web service call to the others. Why second? Because there we have the Case Reference ID, and in the most cases also the first mentioning of the Path Request ID (if it was not specified in the first web service call for dossier creation).
2.1.3 Receipt Confirmation Message For the Path Request issued in this example, the PCS generates the Receipt Confirmation Message which contains all the Identifiers used until the submitting of the Request.
11
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 13 Receipt Confirmation: contains the identifers used in the current process.
Figure 14 The Type of Information is set to 7 - create offer. The Related Type is set to 2006 - Path Request message type code
2.1.4 Path Details Message
This is now the aspect for the IMs. The sending of the Path Details message via PCS from the Coordinating (Leading) IM to RU can be done only if the dossier is fully harmonized (the same rule applies as for RUs for Path Request). Therefore, the web service calls of Path Coordination Message have to be executed in the same way as shown before. The Steps 11 and 13 from our SoapUI example can be used for this purpose.
12
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 15 Path Details Message: please note the sender and receiver, as well as the Case Reference ID and Train ID
13
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 16 Note the Path ID and Type of Information=16 (Final offer)
For the core element of PathID, the PCS specific “path id” of the IM timetable is used.
Figure 17 PCS specific path id used for the core element of PathID
Similarly as for the Path Request and LeadRU, the PCS will send the Path Details messages on behalf of involved IMs to the corresponding RUs.
14
PCS 2018 – TAF/TAP TSI Testing Framework
Note for the PCS experienced users: here we test with the Ad-Hoc process which is the pendant to the TAF TAP TSI Short Term Path Request process in the PCS world. Therefore, we do not send here the “Draft Offer”, but just the “Final Offer”.
As the response of the RU, the Receipt Confirmation message is generated by PCS. The Receipt Confirmation message contains all the identifiers used, and indicates with the type of information to which event it is related (final offer). It also contains the “Related Type” information about the message type code of the message that caused the Receipt Confirmation.
Figure 18 Receipt Confirmation of the Path Details: note the type of information (final offer=16) and the Related Type (message type code 2003 of the Path Details)
15
PCS 2018 – TAF/TAP TSI Testing Framework
The evaluation if everything was successfully executed is done by checking the PCS dossier status. The PCS dossier must be in the Acceptance phase.
Figure 19 PCS Acceptance phase
Path Confirmed Message
If the all involved RUs accept the offer (put their acceptance indicators (PCS traffic lights) to green with Path Coordination Messages), the LeadRU should send the PathConfirmedMessage via PCS to the Coordinating IM.
Figure 20 Path Confirmed Message: note the web service end point, the sender and receiver company and identifiers
16
PCS 2018 – TAF/TAP TSI Testing Framework
Figure 21 Path Confirmed Message: type of Information = 17 - final offer accepted
The PathConfirmedMessage must also contain the identifiers of the corresponding objects – train, path, path request and case reference.
Also in this case, the rule applies for PCS, that the further PathConfirmedMessages are sent by PCS on behalf of the participating RUs.
If everything runs well, the PCS dossier will have to reach the phase “Active Timetable” after the PathConfirmedMessage is processed.
Figure 22 PCS Phase Active Timetable
17
PCS 2018 – TAF/TAP TSI Testing Framework
3 ConclusionThe test with PathCoordnationMessage and PathRequestMessage is especially interesting for Railway Undertakings but it is not limited to only RUs. IMs need at least to check the step 1)-d&e in order to be able to understand the content of the PathRequestMessage which will come to their system. Additionally, it can be useful for IMs to get familiar with the whole process.
- The company that wants to use CI as the interface to PCS has to contact RNE and establish the test plan as a test partner
- Together with the test partner, the dossier in PCS will be initially established to be used in examples.
- The same dossier will be prepared in the PathCoordinationMessage for dossier creation (type of information = 30)
- After that, the steps are executed respectively:o RU-RU Create dossier with PathCoordinationMessage (set the TrainID)o RU-RU Update and harmonize dossier with PathCoordinationMessage (use TrainID
and Case Reference ID for dossier identificatiion)o RU-IM send PathRequestMessage of harmonized dossier (use TrainID,
CaseReference ID and PathRequest ID). o Important: It is sufficient if LeadRU sends the PathRequestMessage via PCS. PCS
will send on behalf of other involved RUs the PathRequestMessage to the corresponding IMs by utilizing the PCS notification service.
o IM-IM coordinate the Path Elaboration phase in PCS dossier with PathCoordinationMessages
o IM-RU LeadIM (similar as LeadRU for PathRequestMessage) sends the PathDetailsMessage, using TrainID, CaseReferenceID, PathID and PathRequestID
Simulate the PathCoordinationMessage and PathDetailsMessage execution by sending it via SoapUI again to the TAF/TAP TSI Web Service Endpoint of CI:
a.i. Login to PCS as the Coordinating IMii. Find the dossier you created by simulating the RU company, as described in
the previous section (Path Coordination Message), in the phase Path Elaboration. Note the dossier_id, and the path_id of the main IM timetable. You will find these easily on the PCS user interface or if you check the XML dossier export (“export” button at the bottom of the Dossier Details page).
b. Change some timetable data in the prepared SoapUI project operation (e.g. times on PlannedJourneyLocations (operation points)) in the PathInformation section, change the TypeOfInformationCode to 08 (draft offer in process) and execute the PathCoordination message via SoapUI.
c. Login to PCS Test System and check the dossier status - the changes made with PathCoordinationMessage execution must be visible in the dossier details and dossier history.
18
PCS 2018 – TAF/TAP TSI Testing Framework
d. Set TypeOfInformation value to 02 (harmonization accepted) to change the IMs acceptance indicator (traffic light) to green. The PathCoordinationMessage has to be sent with this information. The consequences can be seen in PCS Test System when checking the “Control” panel in PCS UI.
e. Set TypeOfInformation value to 16 (final offer) to issue the Final Offer in PCSf. Login to PCS Core Test System and check the dossier status – the dossier must be
in the Acceptance phase.
19
PCS 2018 – TAF/TAP TSI Testing Framework
4 References
Reference Document Description Stored at
20
