A JBoss Project
Red Hat

Latest posts

We’ve been working hard on improving our tooling story for Fuse for a few months. One of the areas we’ve been focusing on specifically has been Transformation tooling. It’s been missing in the JBoss Tools suite for a while now and something we needed to address.

As a result, we ended up with the Fuse Transformation tooling, which I’ll be talking about over the course of a few blog posts.

First, What Exactly Is the Fuse Transformation Tooling?

The last transformation tooling we had in JBoss Tools leveraged Smooks to convert one format to another. This time we’re using the Dozer framework, which offers a great base for handling Java to Java transformations. Through various APIs, you can convert just about anything to a Java model these days and that gives us a good place to start.

With the addition of Fuse technologies (and some awesome developers), we gained some cool new toys in the tooling and a big part of that is the Camel Editor (i.e. the "Fuse Tooling Routes Editor"). The Fuse Transformation tooling builds on that and offers:

  1. the Fuse Transformation Editor, which offers visual editing of a Dozer configuration file

  2. the New Fuse Transformation wizard, which creates a new Transformation file and integrates it as an endpoint in a Camel configuration

  3. and the New Fuse Transformation Test wizard, which creates the outline for a new JUnit test you can run to test your transformation

Though we’re in Tech Preview for now, we have good collection of functionality already and we’ll walk through some of that.

Where Can We Get These Toys?

The new tooling appears in the JBoss Tools Integration Stack "Early Access" site, so be sure to keep up with that effort. (You can see Paul’s latest post here: "JBoss Tools Integration Stack - Luna integration tooling for BRMS/BPMS, Data Virt, SOA 5.x + Early Access Fuse and SwitchYard."

Keep up to date with JBoss Tools Integration Stack to ensure you have the latest version of the Transformation tooling.

Let’s Start With a Use Case - XML to JSON

I’m going to cheat a little and start with the Starter project that we have created for the Transformation project. It includes some sample data to demonstrate transforming from XML to JSON. It includes a sample Camel configuration as well (in either Spring or Blueprint form) that provides a route that takes a file and routes it to another. In this case, we’re going from a sales order in XML format (abc-order.xml) to a sales order in JSON format (xyz-order-schema.json). This is a common integration case where you have to migrate one format to another.

But Wait! Didn’t You Say Dozer Is Strictly Java-to-Java?

Why yes, I did! But I also said that we have ways to create Java models from other formats. And in this first wave of Transformation functionality we offer built-in conversion from XML (XML schemas or instance documents) and JSON (JSON schemas or instance documents) to help get you that far. plus some other, more open-ended capabilities we’ll talk about down the line, we will walk through each step of getting you from your sample data to a fully testable solution.

So let’s get started…​

Launching the Wizard

There are three main ways to launch the New Transformation Wizard in Eclipse…​

  1. From the top-level menu in the Eclipse workbench, use File→New→Other…​ (or Ctrl+N), then look for Fuse Tooling→Fuse Transformation

  2. Right-click on a project in the Project Explorer, select New→Other…​ then look for Fuse Tooling→Fuse Transformation

  3. Open a Camel file (Spring or Blueprint) and drag the Transformation→Data Transformation item from the palette onto the canvas (see below)

launching-the-wizard

New Fuse Transformation Wizard, Start Page

Once you’ve launched the New Fuse Transformation Wizard, you are presented with a wizard page that looks something like the following.

  1. To start, depending on how you’ve launched the wizard, you may have to select the Project explicitly. The drop-down list is populated by a list of all projects that include Camel configurations (either Spring or Blueprint).

  2. The Transformation ID becomes the explicit name of the Dozer endpoint that gets created in the Camel route. We then can reference that endpoint in the route itself. Since we’re transforming an XML file into a JSON file, we’ll call ours "xml2json".

  3. The Dozer File Path calls out the location and name of the Dozer configuration file. It is pre-populated with the name "transformation.xml" and will place the file in the src/main/resource folder of your project, but you can name it whatever you’d like and provide a project-relative path so long as the path can be found in the project classpath. We’ll leave it at the default for now.

  4. The Camel File Path points to the Camel configuration file you are adding this transformation to. In the case below, we have selected the Spring Camel configuration in the starter project.

new-fuse-transformation-wizard-start-page

New Fuse Transformation Wizard, Selecting Types to Transform

Currently with the wizard we have the ability to transform to and from one of four different types:

  • Java (Existing Java model)

  • XML (XML Schema or Instance Document)

  • JSON (JSON Schema or Instance Document)

  • Other (Special case we’ll cover in another post)

Today we’re focused on converting from XML to JSON, so we’ll select those two types and click Next.

new-fuse-transformation-wizard-selecting-types-to-transform

New Fuse Transformation Wizard, Source XML Details

Since we selected XML as the Source Type on the Start page, we’ll see the "Source Type (XML)" page appear next. If we had selected another type, we’d see that page here.

In this case, we have an XML Schema document (abc-order.xml) that we want to transform from. So we’ll click on the Source File field’s "…​" button to browse for our file, select abc-order.xml, and click Next to continue. If you have a particularly complex schema, you may need to select from the root elements you wish to key on for the transformation.

new-fuse-transformation-wizard-source-xml-details

New Fuse Transformation Wizard, Target JSON Details

Since we selected JSON as the Target Type on the Start page, we’ll see the "Target Type (JSON)" page appear next. If we had selected another type, we’d see that page here.

In this case, we have an JSON Schema document (xyz-order-schema.json) that we want to transform to. So we’ll click on the Target File field’s "…​" button to browse for our file, select xyz-order-schema.json, and click Finish to continue.

new-fuse-transformation-wizard-target-json-details

Finishing Up…​

As soon as the wizard is done, you’ll notice two things.

  1. The Fuse Transformation Editor opens so you can edit your new Dozer configuration file.

  2. The Camel Editor has been updated with the new Transformation endpoint you just created. (Notice the "dirty" flag on the "camel-context.xml" tab.)

For now, we’ll close our new Transformation and go back to the Camel route to finish hooking up the new endpoint.

finishing-up

Going back to the Camel editor

When we select the Camel editor again, we notice that a new endpoint reference has been added to the canvas. We need to now hook that into our route so it happens between our source and target steps of this simple configuration.

The first thing we need to do is delete the existing link between the "src" and "target" elements of the route. You can click on it and hit the Delete key on your keyboard or right-click on the arrow and select "Remove." When it asks if you want to remove the element, click Yes.

going-back-to-the-camel-editor

Wiring up our New Endpoint

Now we can wire up the endpoint.

  1. If you hover the mouse over the "src" file element, you’ll see a toolbar pop up. Click and drag the Arrow to our new endpoint.

  2. Do the same thing from the endpoint to the "target" element.

  3. Next, save the Camel editor and it will refresh the view to clean up your route a little.

wiring-up-our-new-endpoint

End for today…​

So now we have a new Transformation endpoint that is wired into our Camel route.

Next time we’ll start doing the actual editing of the Transformation itself!

end-for-today

Thanks for reading!
Brian "Fitz" Fitzpatrick

You may have noticed over the years, that your server view’s context menu has an option labeled "Port Monitoring". You may have also noticed that when using JBoss servers, nothing was ever available there. Recent commits have finally remedied this decade-long omission of a useful feature.

TCP/IP Monitor

The WTP platform includes a TCP/IP monitor as a standalone entity. You can use it manually, which I’ll explain now, but the real magic happens when integrated with our server adapters.

There are two primary pieces to the TCP/IP Monitor. First, there’s a preference page, where you can add port mappings and enable or disable monitoring on that port. Secondly, there’s a TCP/IP Monitor view.

The Preference Page

To see the preference page for port monitoring, you’ll want to go to Window ▸ Preferences ▸ Run/Debug ▸ TCP/IP Monitor. You’ll see the page depicted below.

20150521 monitoring pref page

The general concept of the tool is that, in order to monitor a given port (for example localhost:8080), you "Add…​" a monitor that listens on some new port (7460) and redirects all traffic to the target destination (localhost:8080). Once this is enabled, only requests to your "Local Port", in this case 7460, can be monitored. Traffic that goes directly to 8080 is bypassing the monitor entirely.

If you click "Add…​", you’ll see a few fields to fill out. The "Local Monitoring Port" is the new port that will position itself between origin and destination. Below that, the "Host name" and "Port" represent your actual intended destination. Traffic can be either declared as HTTP or TCP/IP in nature, and you can set a timeout.

Once you’ve added a monitor, you can click on it in the preference page and select "Start", to activate the monitoring on that port.

The View

Once monitoring of traffic has been enabled, you can go ahead and open the view. Window → Show View → Other → TCP/IP Monitor. If you had a wildfly started (either externally or using the server adapters), you could go to http://localhost:7460/ in the browser. The TCP/IP monitoring will be updated with requests and traffic information as shown below.

20150521 monitoring view

Clicking on each individual request will show you both the request on the left side, and the response on the right. It will preview images that were requested, or simply display the contents of any text requests and responses. Headers are also shown for both the request and the response.

Integration with the Servers View

While everything seems to work nicely in the above simple example, tools need to make sure that they make requests to the new Local Port rather than the actual destination. Our recent commits focussed on this deficiency.

To see this in action with the Servers View, you’ll want to open your Servers View. You hopefully already have a WildFly instance installed there, which you can go ahead and start now. When you right-click on your Server Adapter, you’ll see a "Monitoring" menu item. We currently have support for monitoring requests on two ports: the HTTP port (8080, typically) and the management port (9990).

20150521 monitoring server

After that, you can create a web project with a servlet or a simple html file and deploy it to the server. If you then right-click on your resource and select Run As → Run On Server, you should see the browser open up to the URL http://localhost:7460/YourProject/index.html (or similar URL). In this way, the tools have made sure to make all requests to the Local Port when port monitoring is enabled, but to make all requests to the actual destination port when monitoring is disabled.

When your server is in a management-enabled profile, requests made to the WildFly Management port will also show up in the TCP/IP monitor for inspection.

Conclusion

So there we have it: A long-standing omission has finally been put in place. What’s more, other server adapters don’t integrate with this feature as completely as we do. If you were to run the same experiment on the Tomcat adapter, and execute the "Run As → Run on Server" action for a web project’s servlet or html file, the browser will still open up on port 8080, rather than the Local Port which can be used for monitoring. When targeting JBoss and WildFly servers, though, these actions behave as a user would expect and hope.

So get in there and monitor some traffic! Grab a nightly build from our downloads section, or just use our nightly update site directly:

http://download.jboss.org/jbosstools/updates/nightly/mars/

Rob Stryker

Looking for older posts ? See the Archived entries.
back to top