Mock Servers
A mock server is a standalone application that is spin next to the development system and allows other systems to send the requests to it and responds with the pre-defined set of data. In general words, this is a replacement for the real API that we want to avoid calling. The main use cases are:
Avoid calling to expensive 3rd party services during development;
Speed up the testing of the slow external services;
Write the manual/automated tests that assert the correct behavior of the system depending on the response from external API.A mock server imitates a real server by providing realistic responses to requests.
It is simulated to work as a real server so that we can test our APIs and check the response or errors. A mock server behaves like a real server which is used for testing and development purpose.
For unit tests, mock ILS server(s) simulate API calls to and from each library.
Receives calls from test code
Replies with fake responses, initialised by test code
Triggered from unit test code
Why use Mock Servers
A mock API server is useful during development and testing when live data is either unavailable or unreliable. While designing an API, you can use mock APIs to work concurrently on the front and back-end, as well as to gather feedback from developers.
Mock Server allows you to mock any server or service via HTTP or HTTPS, such as a REST or RPC service.
We need a mock server for a number of reasons. A mock server is required
To test your own API while developing and before making that API live on the server of your organisation.
To get feedback and bugs quicker.
For checking the dependencies in your API before it is available to everyone.
For QA engineers to use this for testing/isolating external dependencies and integration testing.
By front end developers to use it before actual endpoints are available. This is done while designing the UI so that you don’t need to wait for the time till actual endpoints are developed. It saves a lot of time.
For engineers to develop prototype of their idea to present it to the investors for funding.
Test Servers
Test servers are used for integration tests, in which ILS test server(s) receive and send real API calls as if they are real live systems, but without modifying a production ILS ensuring that the connections between systems are working properly.
Both types of servers are necessary to properly test whether any changes to the code will work in production.
Receives ILS calls from integration test code
Replies with valid responses
Maintains internal database of test data, initialized by the test suite
Basic Setup
Mock servers are located on the client network. For mock servers to work, Gateway and CIRC server should be working. Mock servers are running in the Docker containers.
Understanding the workflow
The flow when working with the mock server is the following:
Step 1. We have to redirect the requests that were supposed to call the external API to our mock server. In the easiest way, this can be achieved by replacing the 3rd party URL with the mock server URL in the development environment.
Step 2. Mock server receives the request and tries to understand whether it can respond to it . This is achieved by looping through the registered requests matchers and comparing the real request with each of the registered ones. If a match is found (e.g. method, URL, and query parameters are matching) then the step 3 happens — the predefined response is returned.
Step 3. When the mock server matches the request, it will return the predefined response. This response we setup alongside with the request. We can specify each and every aspect of the response — from HTTP code to body and headers.
Princeton University (PUL) and Columbia University (CUL) have SIP2 servers.
NewYork public library (NYPL) has exposed REST API’s
Hence below Mock servers are built:
PUL/CUL SIP2 Mock Server
SIP Server is a TCP/IP-based server that can also act as a messaging interface between SIP Server clients. Once connected the server receives SIP2 request messages from the client and using the instance parameters does the required database lookups, processing etc. and returns the appropriate response message. The parameters define how the data for each field in the response message is derived. When Request is placed to SIP2 server it will convert the request to string and while passing the response it will again convert string to the response
NYPL REST Mock Server
A mock API server imitates a real server by providing realistic responses to requests. Dynamic response can make your mock API more realistic. Responses can be static or dynamic, and simulate the data the real API would return, matching the schema with data types, objects, and arrays. The data can be randomly generated based on the type of field and requirements you determine. For getting the request and sending the response it uses RESTful API Services.
LAS Mock Server
Once a request message is placed to the request queue from SCSB-CIRC, the request message will then be consumed by mock Server. After doing some internal processing, Mock Server will respond by sending a response message to the response queue.Later,SCSB-CIRC will consume the response message.
Setting up the server
There are multiple implementations of the server depending on the environment. The easiest way to set up the server is however to spin the docker image. Instruction and source files can be found here. In the most basic way, starting the server results in just two shell commands:
SIP2 Mock Server
sudo docker run --name phase4-sip2-mock-server --restart always -v /data:/recap-vol -p 8012:8012 -e "ENV=-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/recap-vol/phase4-scsb-mock-nypl-server/heapdump/ -Dorg.apache.activemq.SERIALIZABLE_PACKAGES="*" -Dspring.config.location=/recap-vol/config/external-application.properties" -d phase4-sip2-mock-server
NYPL Mock Server
sudo docker build -t phase4-scsb-mock-nypl-server .
sudo docker run --name phase4-scsb-mock-nypl-server -p 8090:8090 -e "DB_HOST=172.17.0.2" -e "DB_USERNAME=recap" -e "DB_PASSWORD=recap" -e "DB_PORT=3306" -d phase4-scsb-mock-nypl-server
sudo docker inspect phase4-scsb-mock-nypl-server | grep IPAddress
LAS Mock Server
sudo docker build -t phase4-scsb-mock-las-server .
docker images | grep none | awk '{ print $3; }' | xargs docker rmi
sudo docker run --name phase4-scsb-mock-las-server --restart always -v /data:/recap-vol -p 9103:9103 -e "ENV=-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/recap-vol/phase4-scsb-mock-las-server/heapdump/ -Dorg.apache.activemq.SERIALIZABLE_PACKAGES="*" -Dspring.config.location=/recap-vol/config/external-application.properties" -d phase4-scsb-mock-las-server
Example -
Request For Request Item
| Code Block |
|---|
{
"author": "Mathematische Poetik ",
"bibId": "15",
"callNumber": "P311.xM315",
"chapterTitle": "Mathematische Poetik / von Solomon Marcus ; aus dem Rumaenichen uebertragen von Edith Mandroiu.",
"deliveryLocation": "PA",
"emailAddress": "test@gmail.com",
"endPage": "",
"issue": "",
"itemBarcodes": [
"32101074849843"
],
"itemOwningInstitution": "PUL",
"patronBarcode": "45678912",
"requestNotes": "Test",
"requestType": "RETRIEVAL",
"requestingInstitution": "PUL",
"startPage": "",
"titleIdentifier": "",
"trackingId": "",
"username": "",
"volume": ""
}
|
Response for Request Item
| Code Block |
|---|
{
"patronBarcode": "45678912",
"itemBarcodes": [
"32101074849843"
],
"requestType": "RETRIEVAL",
"deliveryLocation": "PA",
"requestingInstitution": "PUL",
"bibliographicId": null,
"expirationDate": null,
"screenMessage": "Message received, your request will be processed",
"success": true,
"emailAddress": "test@gmail.com",
"titleIdentifier": ""
}
|