Camel Quarkus - Rest/Soap Demo

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:

https://developers.redhat.com/articles/2023/10/06/try-camel-quarkus-developer-sandbox-red-hat-openshift

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.

Explore the source code

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:

camelq/level1simple-soap/src/main/resources/routes/api-simple.yaml

Click on the Camel source file to display it in your code editor.

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.

Run the stub in your terminal

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
```
- After Maven downloads all the dependencies, you should see in your terminal logs that the stub has started:
  
  Note
  Two notifications will pop up to inform you of new listening ports. You can ignore these messages; they will automatically close after a few seconds.
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
```
Note
The 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.

Run the service in your terminal

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
```
- Some more dependencies will be downloaded before the engine starts. When done, you should see logs of both systems in both terminals:
  
  Note
  More notifications pop up about the new listening ports. You can ignore these messages; they will automatically close after a few seconds.
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
```
Note
The 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.

Deploy and test the stub

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
```
Note
The 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".
```
Warning
Not 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

Note	The cURL command above now points to the newly deployed pod, with its service `soap1` listening on port `8080`.

Note	The 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.

Deploy and test the main service

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
```
- Maven will interact with OpenShift to deploy the service.
  
  When done, if successful, going back to your browser’s tab with your OpenShift’s developer topology view, you should see both services available, the main service and the stub, up and ready when fully started, looking similar to:
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
```
Note
The cURL command above now points to the newly deployed pod’s Kubernetes service simple, listening on port 8080.

Note
The 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.

Clean up your namespace

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

walkthrough.adoc

walkthrough.adoc

Camel Quarkus - Rest/Soap Demo

Explore the source code

Run the stub in your terminal

Run the service in your terminal

Deploy and test the stub

Deploy and test the main service

Clean up your namespace

Files

walkthrough.adoc

Latest commit

History

walkthrough.adoc

File metadata and controls

Camel Quarkus - Rest/Soap Demo

Explore the source code

Run the stub in your terminal

Run the service in your terminal

Deploy and test the stub

Deploy and test the main service

Clean up your namespace