Challenge Overview
A new project for Hercules is an integration into a Property Management System (PMS). The end product will be a bridge between events raised by the PMS and internal calls to the Hercules services through the VPIL layer we are building in the Node Base Libraries. The PMS server will raise events and our bridge will handle those events by making a series of calls into the VPIL (and other) Base Library services. This challenge will build a mock PMS server we can use for testing.
Mock
We do not currently have a PMS system available for testing, but there are plenty of SOAP WSDLs and documents describing the PMS system in detail and how it will work. This challenge will build out a mock for specific calls:
Link
Have a look at the documentation here: ���http://www.htng.org/page/SpecsbyProductType. This covers the main developer documentation for the system, but it's way more than what we need for the mock.
For the mock, we are concerned with:
* Event notification
* Guest & Room Status Messaging
Server layout
It is expected that your solution will require two Heroku instances - one for the subscription service and one for the subscriber. Each app will have SOAP web services they expose as well as basic UIs so we can review the interactions between the services.
The interactions should follow this flow, allowing us to validate the results during review:
The user / reviewer should be able to load up the registration page for the subscriber app, enter URL details for the subscription service app, hit "Subscribe" and see that a subscription message is sent to the subscription service app.
Next, the reviewer should be able to load up the subscription service app and see that a new subscriber has been added.
Then, the reviewer should be able to send check in, check out, and move messages from the subscription service app and then switch to the subscriber app to see the messages processed.
Subscription Service app
There will be two pieces to the mock that we need. These will be separately deployable services and sites that will work together through the specified interfaces below. The first piece is the subscription flow for events, detailed in the documentation here:
https://htng.site-ym.com/resource/collection/843C598F-F4A4-44F1-A4DC-57507A795B30/HTNG_Event_Notification_v3.0_2015A_Technical_Specification.pdf
Subscription service:
We need a service that mocks and exposes the web services for:
* Get available subscriptions
* Subscribe
* Get subscription status
The service should be mocked based on the common bindings WSDL in the package here:
https://htng.site-ym.com/resource/collection/37207339-2EEA-4DFD-89AA-F04D8F864CB0/HTNG_2011B_GRSM_v2.0_Tech_Spec_FINAL.zip���
Subscription site:
Once we have the service implemented, we can build a very basic UI over the top of it to send mock messages to the subscribers. We also want to view the subscriber's details and remove them for testing.
The subscription service will mock sending these messages to the registered subscribers:
* Check in (HTNG_HotelCheckInNotifRQ)
* Check out (HTNG_HotelCheckOutNotifRQ)
* Guest move room (HTNG_HotelRoomMoveNotifRQ)
Mock subscriber
Once the subscription service is implemented, we can build a mock subscriber app that will respond to the events raised by the subscription service. For this challenge, we can build a basic web app that just consumes the messages and displays them in the UI. Requiring a UI refresh is fine to see the new messages sent.
The mock subscriber should be able to parse out the 3 messages above (HTNG_HotelCheckInNotifRQ, HTNG_HotelCheckOutNotifRQ, and HTNG_HotelRoomMoveNotifRQ), and it should respond with the corresponding response (HTNG_HotelCheckInNotifRS, HTNG_HotelCheckOutNotifRS, and HTNG_HotelRoomMoveNotifRS).
Each message received will just be displayed in a page, allowing us to see the messages sent and received.
Registration page:
The mock subscriber should have a page that allows a user to subscribe the page to the subscription service. The page should include a text box for the URL to the subscription service and a button that says "Subscribe" that will send the necessary subscription message for the events.
Node / Heroku
For this challenge, we are targeting the latest version of Node and Heroku for deployment. For storing the messages, you can use Redis or MongoDB - either is fine.
Please make sure to provide a way to clear out the messages in the subscriber for easy testing.
Mock
We do not currently have a PMS system available for testing, but there are plenty of SOAP WSDLs and documents describing the PMS system in detail and how it will work. This challenge will build out a mock for specific calls:
Link
Have a look at the documentation here: ���http://www.htng.org/page/SpecsbyProductType. This covers the main developer documentation for the system, but it's way more than what we need for the mock.
For the mock, we are concerned with:
* Event notification
* Guest & Room Status Messaging
Server layout
It is expected that your solution will require two Heroku instances - one for the subscription service and one for the subscriber. Each app will have SOAP web services they expose as well as basic UIs so we can review the interactions between the services.
The interactions should follow this flow, allowing us to validate the results during review:
The user / reviewer should be able to load up the registration page for the subscriber app, enter URL details for the subscription service app, hit "Subscribe" and see that a subscription message is sent to the subscription service app.
Next, the reviewer should be able to load up the subscription service app and see that a new subscriber has been added.
Then, the reviewer should be able to send check in, check out, and move messages from the subscription service app and then switch to the subscriber app to see the messages processed.
Subscription Service app
There will be two pieces to the mock that we need. These will be separately deployable services and sites that will work together through the specified interfaces below. The first piece is the subscription flow for events, detailed in the documentation here:
https://htng.site-ym.com/resource/collection/843C598F-F4A4-44F1-A4DC-57507A795B30/HTNG_Event_Notification_v3.0_2015A_Technical_Specification.pdf
Subscription service:
We need a service that mocks and exposes the web services for:
* Get available subscriptions
* Subscribe
* Get subscription status
The service should be mocked based on the common bindings WSDL in the package here:
https://htng.site-ym.com/resource/collection/37207339-2EEA-4DFD-89AA-F04D8F864CB0/HTNG_2011B_GRSM_v2.0_Tech_Spec_FINAL.zip���
Subscription site:
Once we have the service implemented, we can build a very basic UI over the top of it to send mock messages to the subscribers. We also want to view the subscriber's details and remove them for testing.
The subscription service will mock sending these messages to the registered subscribers:
* Check in (HTNG_HotelCheckInNotifRQ)
* Check out (HTNG_HotelCheckOutNotifRQ)
* Guest move room (HTNG_HotelRoomMoveNotifRQ)
Mock subscriber
Once the subscription service is implemented, we can build a mock subscriber app that will respond to the events raised by the subscription service. For this challenge, we can build a basic web app that just consumes the messages and displays them in the UI. Requiring a UI refresh is fine to see the new messages sent.
The mock subscriber should be able to parse out the 3 messages above (HTNG_HotelCheckInNotifRQ, HTNG_HotelCheckOutNotifRQ, and HTNG_HotelRoomMoveNotifRQ), and it should respond with the corresponding response (HTNG_HotelCheckInNotifRS, HTNG_HotelCheckOutNotifRS, and HTNG_HotelRoomMoveNotifRS).
Each message received will just be displayed in a page, allowing us to see the messages sent and received.
Registration page:
The mock subscriber should have a page that allows a user to subscribe the page to the subscription service. The page should include a text box for the URL to the subscription service and a button that says "Subscribe" that will send the necessary subscription message for the events.
Node / Heroku
For this challenge, we are targeting the latest version of Node and Heroku for deployment. For storing the messages, you can use Redis or MongoDB - either is fine.
Please make sure to provide a way to clear out the messages in the subscriber for easy testing.