The order of the assign and transform in the Mediator

In my previous blogpost I pointed out the usage of an assign in a mediator component. This can be useful over the transform in several cases. Besides using one of the two, it is also possible to use them both in the same route. I would not advise using both the assign and the transform to manipulate the same data object, however this is possible.

If you want to do this, it is good to keep in mind in which order the mediator handles the manipulations. I used the same example from the previous blogpost and added an transformation in the mediator.

In the transform, I copy the firstname from the input, to the lastname of the output:

 

Resulting in both a transform and an assign in the mediator:

 

I deployed the service to the Enterprise Manager and will fire the following test:

 

The response already clarifies what happened here, the transform is fired first and only after the transform is done, the assign is being processed, because the input is the same as the output:

 

However, to verify this assumption, we will have a closer look at the flow trace, in the flow trace, we open the instance of the mediator:

 

In here we can clearly see that the xsl transformation is done before the assign.
Keep this in mind when you want to use both the transform as well as the assign option on the same data object in the mediator.

Use the assign instead of a transform in the Mediator

When building less complex services, your BPEL process often uses input and output that is pretty much like the request and response on the wsdl. We would still want to decouple using the mediator component, so there is an extra transformation there which is pretty straight forward.
Sometimes it can be useful, easier and faster to use a assign in the mediator instead of a transform.

Imagine an pretty straight forward xsd:

I created an example BPEL process, also pretty straight forward. The Person is both the input and the output, all the BPEL process does is copy the input to the output and reply it:

 

In the Create Web Service dialog we create a WSDL based on the same XSD, also with a Person as input and output:

As said, because of decoupling, we would still want to have a mediator between the exposed service and our bpel process. We create a mediator and wire it both to the service and to the bpel process.
However, when editing the route, we usually use a transformation to map the input to the output, in this case, we are going to use an assign:

When you click the assign button, this also pop ups and Assign Values dialog, here we can wire the input element to the output element:

This way we use an assign in the mediator instead of creating an xsl transformation for this pretty straight forward transformation.

Switch the Audit Level to Development mode

With JDeveloper 12c it is now possible to run your SOA Suite against the Integrated WLS. However, by default the Audit Level of this server is Production mode which means you do not get to see details when looking at the flow trace of your service.
If you do not change your running mode, the flow trace window will look like this:

We will switch the Audit Level of your local SOA domain to Development mode, to get more info in the flow trace. Right click on your soa-infra, go to the SOA Administration and select the Common Properties:

Change the Audit Level to Development and click Apply:

You do not need to restart your server after this. However, you do need to test your service again. Test your service and again go to the flow trace, the result should now look like this:

You can now press the ‘View Payload’ to see the payload of your transformation:

Run ADF & SOA on the IntegratedWLS in separated domains

In JDeveloper 12c, it is possible to run SOA Suite on the InternalWLS, which is a great feature. However, once you have done this, your domain will be filled with SOA extensions. Meaning the server start up time will increase drastically.
When you do both ADF & SOA development, this can be annoying when you just want to run your ADF application and the IntegratedWLS is busy starting up the SOA domain. One way to avoid this is to run two different JDeveloper instances with two different Jdev Homes configure.
In this blog I will describe you how to set this up.

First of all, I got my ‘normal’ JDeveloper for ADF development, this is installed on my C drive, under: C:\oracle\JDev1213, if you navigating to the Oracle_Home\jdeveloper\jdev\bin folder and open the jdev.boot file, you will see the variable ‘ide.user.dir.var’:

Now I recently installed a second JDeveloper 12c in a different directory, this JDeveloper is installed with the SOA extensions, I installed this on the C drive as well, but in the folder C:\oracle\JDevHomeSOA. Within this JDeveloper folder, there is also a jdev.boot file under the folder ‘\jdeveloper\jdev\bin’, however, I changed the ‘ide.user.dir.var’ to a specific _SOA variable:

Now all that is left to do is to create two new Environment Variables, pointing to different JDevHome directories:

This will create two different domains for each JDeveloper, keeping your environment clean and tidy!

Stretch your table to full page

In a previous blog I mentioned dynamic stretching table height with the autoHeightRows property. However, I have noticed people are having more troubles with stretching the height of the table.

This time I will focus on stretching your table to fill the total page height. We start with a simple ADF table on the employee table, showing all employees. Although I have seen more complex questions, including regions and more components in the structure, it all comes down to the same principle. I created a pretty straight forward jsf file with the following structure:

On the panelCollection I have set the styleClass AFStretchWidth to stretch the table to the full width of the page, however, by default it will not stretch the full height, but it will look like this:

Especially when you have a more complex structure, with more layout components in your page, it is easy to think you configured something wrong, however, this is the default behavior even when you use the panelStretchLayout.
In the documentation of the panelStretchLayout you can read up on the Geometry Management, it is important to focus on the section about the ‘dimensionsFrom’ property. The default value is read from the web.xml context-param ‘oracle.adf.view.rich.geometry.DEFAULT_DIMENSIONS’ which results in ‘auto’.
However, for our page we want the table to take the dimensions from parent. You can set the dimensionsFrom="parent" on the panelStretchLayout on your page, or you can override the default in the web.xml parameter.
The result will be the same, a table shown over the full page: