Explore, build, test and deploy a Camel Quarkus demo application using the Developer Sandbox and OpenShift Dev Spaces.
This hands-on lab is based on the following blog article in Red Hat Developers:
Assuming you have followed the article’s instructions, you should be all set to get hands-on with Camel Quarkus in the OpenShift Dev Spaces workspace.
For illustration purposes, the picture below shows what the integration end-to-end flow looks like.
A client invokes an OpenApi service. A Camel route attends the call, translates the JSON input into SOAP and calls a backend service to obtain a SOAP response, then it’s translated back to JSON before responding to the original service call.
Take aways for this lab:
-
Try out an OpenShift environment.
-
Work in a full browser based IDE environment.
-
Build, deploy and test a Camel Quarkus application.
-
Adopt contract-first approach for both REST and SOAP.
-
Define direct JSON ⇄ SOAP transformations using XSLTs.
-
Discover and test REST operations using Swagger UI.
-
Learn how to implement both SOAP client/server sides.
The Camel source file api-simple.yaml
defines the entire end-to-end processing logic, which you can find in your project explorer under the path:
Inside the Camel source you’ll see the main route definition:
The key processing actions are:
-
Performs the JSON to SOAP transformation.
-
Invokes the SOAP backend service.
-
Transforms the SOAP response into JSON.
The code above is written using the YAML DSL (Domain Specific Language), but Camel also provides a Java DSL and an XML DSL.
Feel free to explore other regions of the code and project if you are curious about the entire implementation.
Interesting areas of the code you can look at are:
-
OpenApi definition in the
openapi.json
resource.-
Used in a
Maven
plugin to auto-generate Camel’s REST DSL.
-
-
WSDL definition to declare the SOAP service.
-
Used by Quarkus to auto-generate the SOAP Java classes.
-
-
CXF endpoint definition in the
Routes.java
source file.-
Uses the auto-generated SOAP Java classes.
-
-
2-way JSON/SOAP transformations using XSLT definitions.
-
Uses XSLT’s out-of-the-box json/xml xpath converters.
-
-
Junit to test/validate the implementation.
-
Spins up a SOAP backend service.
-
Validates the REST request/response
-
Validates the SOAP request sent to the backend.
-
The stub acts as the SOAP backend service that provides the SOAP data we need to fetch.
-
Open your terminal
Make sure you make your terminal visible in the IDE. You can toggle it using the keyboard keys Ctrl+` or simply find the option from the menu system as per the picture below:
-
Let’s first run the stub
Copy and paste the following command in your terminal to place yourself in the stub’s Camel Quarkus project:
cd camelq/stubs/soap1
Then, copy/paste the following command to start the stub in the terminal:
./mvnw clean compile quarkus:dev -Ddebug=6006
Now, test your stub from a new terminal. From your terminal’s top right corner, choose the Split option, as shown below:
Copy/paste the following cURL command to obtain a response from the stub:
curl -s \ -d @src/main/resources/request.xml \ http://localhost:9000/services/s1 \ | xmllint --format - \ | bat -pP -lxml
NoteThe command also includes pipes to pretty-print and colorize the SOAP output for better reading. The invocation should return a SOAP payload similar to:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:SubscriberResponse xmlns:ns2="http://www.example.org/s1/"> <Name>Some</Name> <Surname>One</Surname> <Address> <Number>1</Number> <Street>Some Street</Street> <City>Somewhere</City> <PostCode>SOME C0D3</PostCode> <Country>UK</Country> </Address> </ns2:SubscriberResponse> </soap:Body> </soap:Envelope>
Did you obtain the same SOAP message as shown above?
You’ve successfully tested the stub !!
Inspect in the stub logs to investigate the possible causes of failure.
The main Camel service exposes a JSON REST API and integrates with the SOAP backend service (the stub).
-
Run the main service
Copy and paste the following command in your terminal to place yourself in the main Camel Quarkus project:
cd /projects/devsandbox-camel/camelq/level1simple-soap/
Then, copy/paste the following command to start the REST service in the terminal:
./mvnw clean compile quarkus:dev
Open a third terminal from which you can issue commands. From your terminal’s top right corner, choose the Split option as shown below:
Copy/paste the following cURL command to obtain a response from the stub:
curl -s \ -H "content-type: application/json" \ -d '{"id":"123"}' \ http://localhost:8080/camel/subscriber/details | jq
NoteThe command includes a pipe to parse the JSON response with JQuery, which nicely renders the returned JSON payload. The cURL command should return a JSON payload similar to:
{ "fullName": "Some One", "addressLine1": "1 Some Street", "addressLine2": "Somewhere SOME C0D3", "addressLine3": "UK" }
Did you obtain the same JSON response as the one shown above?
You’ve successfully tested the main service !!
Inspect in the stub logs to investigate possible causes of failure.
The stub acts as the SOAP backend service that provides the SOAP data we need to fetch.
-
Stop both systems
Make sure you stop both the stub and the main service by selecting each terminal and pressing the keys Ctrl+c. Your view of your terminals should look like:
-
Deploy the stub
Make sure your CLI
oc
client (OpenShift client) points to your Developer Sandbox project (aka namespace):oc projects -q | grep dev | xargs oc project
NoteThe Developer Sandbox only allows 1 project (namespace) per user. The command above should output something similar to:
Now using project "<your-username>-dev" on server "https://172.30.0.1:443".
WarningNot specifying your target project (namespace) in OpenShift may result in a deployment failure. You can now copy and paste the following command in your terminal to trigger the deployment:
./mvnw clean package -DskipTests -Dquarkus.kubernetes.deploy=true
-
You’ll see Maven fetching more dependencies and then interact with OpenShift to finalise the deployment of the stub.
When done, if successful, going back to your browser’s tab with your OpenShift’s developer topology view, you should see the new service up and ready when fully started, looking similar to:
-
-
Test the stub
Copy/paste the following cURL command to obtain a response from the stub:
curl -s \ -d @src/main/resources/request.xml \ http://soap1:8080/services/s1 \ | xmllint --format - \ | bat -pP -lxml
NoteThe cURL command above now points to the newly deployed pod, with its service soap1
listening on port8080
.NoteThe command also includes pipes to pretty-print and colorize the SOAP output for better reading. The invocation should return a SOAP payload similar to:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:SubscriberResponse xmlns:ns2="http://www.example.org/s1/"> <Name>Some</Name> <Surname>One</Surname> <Address> <Number>1</Number> <Street>Some Street</Street> <City>Somewhere</City> <PostCode>SOME C0D3</PostCode> <Country>UK</Country> </Address> </ns2:SubscriberResponse> </soap:Body> </soap:Envelope>
Did you obtain the same SOAP message as shown above?
You’ve successfully tested the stub deployed in the sandbox !!
Inspect in the stub logs to investigate possible causes of failure.
With the stub already deployed, we just need to deploy the service which will integrate with the stub running under the same namespace.
-
Deploy the service
Ensure you run the commands below from the terminal located in the path of your main service project.
You can now copy and paste the following command in your terminal to trigger the deployment:
./mvnw clean package -DskipTests -Dquarkus.kubernetes.deploy=true
-
Test the service
Copy/paste the following cURL command to obtain a response from the
simple
service:curl -s \ -H "content-type: application/json" \ -d '{"id":"123"}' \ http://simple:8080/camel/subscriber/details | jq
NoteThe cURL command above now points to the newly deployed pod’s Kubernetes service simple
, listening on port8080
.NoteThe command also includes a pipe to parse and colorise the JSON output for better reading. The invocation should return a JSON payload similar to:
{ "fullName": "Some One", "addressLine1": "1 Some Street", "addressLine2": "Somewhere SOME C0D3", "addressLine3": "UK" }
-
Invoke the service as an external client
Notice the previous cURL command uses an internal service URL, which is not directly accessible by external consumers. However, the deployment automatically creates a route in OpenShift that exposes the service to external clients.
You can obtain the route details with the following command and use its URL from your favourite local HTTP client/tester, like Postman, Swagger or others.
oc get route simple
Embedding
oc get route
into commands allows you to discover and invoke the service as an external consumer.-
For example, copy/paste the following cURL command to simulate an external call and obtain a response from the Camel service:
curl -s \ -H "content-type: application/json" \ -d '{"id":"123"}' \ http://`oc get route simple -o jsonpath={.spec.host}`/camel/subscriber/details | jq
The invocation should return a JSON payload similar to:
{ "fullName": "Some One", "addressLine1": "1 Some Street", "addressLine2": "Somewhere SOME C0D3", "addressLine3": "UK" }
-
You can also use the server’s Swagger UI from your browser to trigger an external call from your computer. Copy/paste the following command to obtain Swagger’s URL:
echo http://`oc get route simple -o jsonpath={.spec.host}`/q/camel/openapi.json
Then, click on the URL generated and follow the link as per the image below:
Following the actions above should open the following view:
-
Click on the
POST
operation. -
Click on
Try it out
-
Click on the blue button
Execute
You should see again the following response:
{ "fullName": "Some One", "addressLine1": "1 Some Street", "addressLine2": "Somewhere SOME C0D3", "addressLine3": "UK" }
-
-
Did you obtain the same JSON response as shown above?
You’ve successfully invoked the simple service as an external client !!
Inspect in the stub logs to investigate possible causes of failure.
When you’re done playing in the Developer Sandbox, you can clean up your Sandbox namespace by un-deploying your Camel simple
service and stub soap1
using the following commands:
oc get all -o name | grep simple | xargs oc delete
oc get all -o name | grep soap1 | xargs oc delete
Executing the commands above should leave your topology view clean from routes, services, and other Kubernetes artifacts in your namespace.
Is your namespace clean from artifacts?
You’ve successfully cleaned up your namespace !!
Inspect in the stub logs to investigate possible causes of failure.