Development of Transactional Data Specifications for Demand-Responsive Transportation (2020)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

135 Validation Tool A P P E N D I X F The research team developed a software tool hosted on a publicly accessible website that enables interested parties to test transactional data messages that could be transmitted among interacting software systems which manage demand-responsive transportation services. These transactional data messages can be sent using either XML or JSON data structures, in accordance with the data specification that is included with this document (see Appendix E). The website that hosts the data validation service is found at the following URL: http://tcrp.demandtrans.com This data validation service aims to provide interested parties with the following capabilities: (1) The ability to test the proposed data specification and identify any issues associated with either the specification or its implementation. (2) The ability to simulate how their software system could interoperate with other software applications that manage demand-responsive transportation services. In order to implement the transactional functionality of the data specification generated by this project, the research team has recommended a “control module” approach to data communication among software systems. This control module approach is briefly explained below. Each software system and device used by demand-responsive transportation services will have its own internal data communication approach and protocols. When a software system needs to interoperate with another software system, it will do so via an interface with an internal or external “data translator” that transforms its internal data messages and their elements into the common transactional data protocol. This data translator in essence performs the function of an internal/external API (application programming interface) for each technology system, enabling it to “speak” in the transactional language when it needs to communicate with other systems. The “control module” approach, which is shown in Figure F-1 and also found in Chapter 4, ensures an element of centralized specification control without requiring a fully centralized translation broker approach. The control module is essentially a data specification validation service. The purpose of this software tool is to enable interested parties to test the proposed data specification. Any organization that uses this software tool will be emulating the process that the proposed transactional data specification approach will support.

136 Development of Transactional Data Specifications for Demand-Responsive Transportation Figure F-1. Control module approach. The website that hosts the data validation service is shown in Figure F-2 below and can be found at the following URL: http://tcrp.demandtrans.com The control module approach necessitates that software systems using the specification be able to internally translate their transactional data into the message types and data elements of the proposed specification. To use the validation service tool described in this document, it is possible for interested parties to generate test data messages without actually modifying their software systems. However, the data that they transmit to this project’s data validation service will need to be translated—by whatever means is necessary—into the required form of the proposed transactional data specification. Figure F-2. Screenshot of website with the transactional data specification validator.

Validation Tool 137 The following is a sample piece of XML that could be sent to the validation service: <tripTask xmlns="http://www.tcrp.gov/schema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tripTaskId>tripTaskId0</tripTaskId> <tripTicketId>tripTicketId0</tripTicketId> <customerLocInDropoffSequence>10</customerLocInDropoffSequence> <nodeAddress> </nodeAddress> <nodeScheduledTime time="2016-05-04T18:13:51.0"/> </tripTask> The following is a sample piece of JSON that could be sent to the validation service: { "tripTask": { "tripTaskId": "tripTaskId0", "tripTicketId": "tripTicketId0", "customerLocInDropoffSequence": "10", "nodeAddress": " ", "nodeScheduledTime": { "time": "2016-05-04T18:13:51.0" } } } A typical API call to this validation service would have the following format: [Http POST] http://tcrp.demandtrans.com/api/Validator/validate?schema={schema}&inputType={inpu tType}&input={input} Questions or concerns about the validator can be sent via email to roger.teal@demandtrans.com.