Tag: Tips ‘n’ tricks

Dynamic adaptation of Coach Views in IBM BPM v8.0

In a previous blog, we have shown  how to create a basic coach view. Since then, I have been doing some more experimenting to achieve dynamic adjustment of view components. It’s hard to admit, but I have spent quite some time, figuring out how to dynamically hide, show or disable a certain view component (e.g. text box), based on a value of a defined configuration option. In my defense, current IBM documentation didn’t offer as much help as it should. (more…)

, , , , , , , , , , Hide

In this post we continue with BO deserialization of a remote XML file over HTTP. In the previous part (if you haven’t read the first part, I strongly suggest you do so) we have statically set the HTTP endpoint (binding on HTTP Import) to the XML file on the HTTP server (http://localhost:8080/NewCustomer.xml). Since this approach is not useful we will illustrate how to use a mediation component to dynamically set the XML file endpoint. If we briefly take a look at our getCustomer operation we can see it has an input field (string) through which we will set the XML file location (endpoint):

Our assembly diagram now look like this:

It contains a mediation and HTTP Import; both have the same interface (CustomerInterface). We will set (override) the endpoint in the mediation flow – request flow looks like this:

It has a HTTP Header Setter and a Trace mediation primitives. HTTP Header Setter mediation primitive can be used for changing, copying, adding and deleting HTTP headers. In our case we will dynamically override the endpoint with value provided by the input message. We must add a new HTTP Header Element and set it like this:

  • Mode: Create
  • Header Name: DynamicOverrideURL
  • XPath Value (we read a value from input message): body/getCustomer/input

HTTP Header Setter

Trace mediation primitive is used only for tracing the message (so we can see it in the console). Message looks like this:
HTTP Header Setter

If we take a look at HTTPHeader we can see the DynamicOverrideURL element which contains our endpoint url (http://localhost:8080/NewCustomer.xml) that we propagated through input string.

So, that’s the end of BO deserialization from remote XML file over HTTP on WAS. I hope it was informative and helpful.
Project interchange ZIP can be found here and the XML file is here.

, , , , , , , , , , Hide

WebSphere Process Server caches information from external people directory such as LDAP. When you use such a directory, changes to it are not reflected immediately in the Process Server. Process Server cache can be refreshed manually (e.g. for development and urgent purposes) or automatically (e.g. for regular operation). (more…)

, , , , , Hide

Last week we have talked about Increasing the JVM heap size in WAS7. We have identified some problems that may arise from too small heap size for our server. Same thing can occur in our development tools based on Eclipse such as WebSphere Integration Developer.


, , , , , , Hide

Increasing the JVM heap size in WAS7

Intensive use of WAS7 often slows down the server because of too often garbage collection. Most frequently this situation arises when WAS profile is augmented with at least two products, i.e. WPS and Monitor or WPS and Fabric. This situation can be avoided by increasing the JVM heap size. JVM heap size can be increased through administrative console or by using scripting. (more…)

, , , , , , , Hide

Let’s say you need to convert data from a remote XML file (located on a remote server) into business object. In our scenario we have a Customer business object (schema) and CustomerInterface which are defined like this:

Input parameter will be used in part 2 and will define XML file URL. In this part XML file URL will be statically configured. Output is a Customer business object that we need in our service or process.

On the server we have the following XML file:

So how to deserialize data form a remote XML file into a business object over HTTP?
The most elegant solution is to use HTTP Import component (HTTP binding overview can be found here):

  1. Make sure remote XML file is accessible and valid.
  2. Create a HTTP Import Service with an interface (more info).
  3. In the properties window of HTTP Import component we must define:
    • Endpoint URL (XML file URL in our case)
    • HTTP version and method
    • Default data format handler – we will use UTF8XMLDataHandler (more info). It converts UTF-8 encoded XML data into business object and vice versa.
    • In the Method Bindings section you can also set: data serialization data handlers (for input and output), HTTP Header (character set, media type, etc.), HTTP Proxy, Security and Performance (read timeout and number of retries). In our case we will leave the default settings.


When endpoint URL and proper data handlers (UTF8XMLDataHanler in our case) are configured, we can test our component. Content of the input message is irrelevant since endpoint URL is statically configured. Let’s see the result:

We have successfully deserialized a Customer business object from a remote XML file. In part 2, we will include mediation component that will allow us to dynamically set endpoint URL for the XML file.

, , , , , , , , , , Hide

In case you wanted to publish your applications directly from WebSphere Integration Developer to the remote WebSphere Process Server you might have come across the situation where you are able to add a remote server in your WID environment but when you try publishing your projects to the server, you receive the following error: “Failure uploading archive to server”.

failure uploading archive to server

It is a simple issue but it can take a lot of time to solve it if you don’t know where to look and I must say that the above message isn’t the most informative one I’ve ever seen. However, I have discovered that this happens if your server is not a member of domain at the time of installation and WID is unable to recognize the hostname, written in the configuration file. (more…)

, , , , , , Hide