Challenge Overview
A new piece of functionaltiy for the Hercules Retail App is an integration into a Order Management Service (OMS). We have access to an integration environment from the client, but it's not overly complete and we're having a hard time testing and validating all the various edge cases.
This challenge will build a SOAP service mock using the OMS WSDL provided in the forum that supports a set of sample messages.
Note that not all the WSDL functionality will be required, only the operations detailed below.
Mock
This challenge will be a mock, but it will be backed by a persistent store. The OMS allows the caller to add and remove devices associated with a given account, so we want to make sure that we:
1. Initialise a default set of devices for a request for a given account that isn't already in the data store
2. Allow the caller to add and remove devices and have the changes reflected in the API
WSDL
The WSDL is provided in the forum. We will focus on these calls:
* queryAccountDevices
* MACDDevices
* RMARemoveDevice
queryAccountDevices just returns the devices for a given account number. For the mock, we will return a configurable set of devices for any account that hasn't been requested or has devices registered in the database. Basically, we don't want to fail on a request for a given account - we will just return a configurable, default set of devices the first time an account is requested. After that point, if the user makes changes through MACDDevices or RMARemoveDevice, then the list of devices will be the edited list
MACDDevices allows the user to swap a current piece of hardware for a new piece of hardware, or just add a new piece of hardware to a customer account.
RMARemoveDevice removes a device from a user account.
WSDL endpoint
Calling {server URL}/OrderManagementService/15.09?wsdl should return the WSDL for the service. This should be the FULL WSDL, not just the implemented calls. If the caller attempts an operation not in scope, we'll just return a SOAP fault that says something like "This operation is not yet implemented in the mock"
Security
The real service uses WSSE security with a username and password for security on the SOAP endpoint. The mock must also support this with a configurable username and password.
Request header
The request header shown in the examples is required to be validated by the mock. Please just make sure the mock checks that all fields are available - we don't have to do anything beyond that.
Unit tests
Unit tests are required for this challenge. Please make sure they cover positive and negative cases for the mock calls.
Video
No video is required for this challenge.
Node / Heroku
For this challenge, we are targeting the latest version of Node and Heroku for deployment. For storing the messages, using MongoDB is fine, but we're open to other persistent storage technologies as well. You can use something like Apache Axis for the development, but really any technology that can be used to meet the requirements above is fine.
Please make sure all configuration is easily done using Heroku environmental variables so we can change things at runtime, without having to redeploy.
This challenge will build a SOAP service mock using the OMS WSDL provided in the forum that supports a set of sample messages.
Note that not all the WSDL functionality will be required, only the operations detailed below.
Mock
This challenge will be a mock, but it will be backed by a persistent store. The OMS allows the caller to add and remove devices associated with a given account, so we want to make sure that we:
1. Initialise a default set of devices for a request for a given account that isn't already in the data store
2. Allow the caller to add and remove devices and have the changes reflected in the API
WSDL
The WSDL is provided in the forum. We will focus on these calls:
* queryAccountDevices
* MACDDevices
* RMARemoveDevice
queryAccountDevices just returns the devices for a given account number. For the mock, we will return a configurable set of devices for any account that hasn't been requested or has devices registered in the database. Basically, we don't want to fail on a request for a given account - we will just return a configurable, default set of devices the first time an account is requested. After that point, if the user makes changes through MACDDevices or RMARemoveDevice, then the list of devices will be the edited list
MACDDevices allows the user to swap a current piece of hardware for a new piece of hardware, or just add a new piece of hardware to a customer account.
RMARemoveDevice removes a device from a user account.
WSDL endpoint
Calling {server URL}/OrderManagementService/15.09?wsdl should return the WSDL for the service. This should be the FULL WSDL, not just the implemented calls. If the caller attempts an operation not in scope, we'll just return a SOAP fault that says something like "This operation is not yet implemented in the mock"
Security
The real service uses WSSE security with a username and password for security on the SOAP endpoint. The mock must also support this with a configurable username and password.
Request header
The request header shown in the examples is required to be validated by the mock. Please just make sure the mock checks that all fields are available - we don't have to do anything beyond that.
Unit tests
Unit tests are required for this challenge. Please make sure they cover positive and negative cases for the mock calls.
Video
No video is required for this challenge.
Node / Heroku
For this challenge, we are targeting the latest version of Node and Heroku for deployment. For storing the messages, using MongoDB is fine, but we're open to other persistent storage technologies as well. You can use something like Apache Axis for the development, but really any technology that can be used to meet the requirements above is fine.
Please make sure all configuration is easily done using Heroku environmental variables so we can change things at runtime, without having to redeploy.