Implement Service Gateway using IBM WESB V7.0

Introduction

WebSphere® ESB V7.0 introduces the Proxy Gateway pattern extending the capabilities of the Static and Dynamic Service Gateway patterns that were introduced in WebSphere ESB V6.2. This sample demonstrates a typical Service Gateway scenario showing built-in routing capabilities of the proxy gateway.

Service Gateway is a typical mediation has a single service consumer and a single service provider (or multiple service providers of the same type). The mediation acts as an intermediary between the two entries completing any processing, such as message manipulation, on the way. There is a separate mediation for each service provider and service consumer. This scenario is shown in Fig 1.

By using the Service Gateway pattern logic the mediation can be written once and used across all service interactions. The Service Gateway pattern provides the ability to have a single mediation that will handle the request for multiple service consumer types and service provider types, as shown in Figure 2. 

Overview

This sample creates a Proxy Gateway, which is a type of Service Gateway.

Architecture of the Proxy Gateway

The concept of a Proxy Gateway is based on the primary goal of a Service Gateway: to provide a generic capability across a multitude of service providers. The diagram below shows the relationship between a Proxy Gateway, Proxy Group, Service Provider and Virtual Service.
General processing template of a Gateway where Service consumers go into the mediation component through a virtual service.

Ø  Proxy Group: collection of Service Providers that can be grouped together into a logical set.

Ø  Proxy Gateway: The entities that will complete the Gateway function for one or more Proxy Groups.

Ø  Virtual Services: the exposed endpoint of the Proxy Gateway for each service provider within the associated Proxy Group

Implementation

We need to complete the following steps to build our application.

Ø  Create a Proxy Gateway.

Ø  Deploy Proxy Gateway.

Ø  Business Space configuration.

Ø  Test the application.

Create a Proxy Gateway:

Use the Proxy Gateway wizard to build a Proxy Gateway:

Open WebSphere® Integration Developer in a new workspace.

Select Window > Show view > Patterns Explorer to open the Patterns view, as shown below.

Create a new Proxy Gateway in the Patterns Explorer tab. Right-click Proxy Service Gateway and select Create New Instance.

Enter EAIProxyGateway as the Integration Solution name and click OK. The New Pattern Instance panel opens, as shown in below.

Accept the default configuration for the Proxy Gateway and click Generate. The Proxy Gateway wizard generates the required artifacts and a summary panel opens.

Scroll down and click the requestResponse Request Flow diagram to open the Mediation Flow Editor. A single Gateway Endpoint Lookup primitive is created by default.

Select the Gateway Endpoint Lookup Primitive and go to properties à Details. The panel should similar to this:

The details section shows the Lookup Method selected (URL) and populates a default Proxy Group called EAIProxyGateway ProxyGroup. When the application is installed, WebSphere ESB will check if EAIProxyGroup exists. If not, WebSphere ESB will create a new Proxy Group within the built-in configuration store and create an association between the Proxy Gateway and Proxy Group.

When the application is removed from the runtime the association between the Proxy Gateway and Proxy Group is removed, but the Proxy Group configuration remains. You can redeploy the application without losing configuration information associated with the Proxy Group (such as Virtual Services).

You can delete the Proxy Group manually using the Business Space console, when there are no associated Proxy Gateways.

The generation of the Proxy Gateway is now complete and the mediation module can be deployed on the runtime environment.

Deploy Proxy Gateway:

To be able to run and test this application it must be built and deploy the application.

If you did not build the sample yourself, you must import the completed sample application. Download the samples from Download Section and import the Proxy Gateway.zip project interchange file.

When you have imported the project, build and deploy the EAI_AccountServiceand the EAIProxyGateway_Gateway projects to a WebSphere ESB 7.0 server. Use the Add/Remove Projects option in the context menu to define a server in the Servers view, or install the server by using the Administration Console.

Business Space configuration:

To access the Business Space console open a Web browser and go to: http://<hostname>:<port>/BusinessSpace.

For example, http://localhost:9444/BusinessSpace

Note: the <hostname>:<port> name varies based on your server configuration.

The login screen is displayed.

In the User ID name field enter admin, and in the Password field, enter admin.

Note: When using Business Space for the first time the welcome screen is displayed. Within Business Space there are spaces, templates, pages and widgets. A space is a collection of pages that can be built based on a template, and a page can contain a number of widgets. WebSphere ESB and WebSphere Process Server include a number of built-in templates and widgets to provide an enhanced ready-to-use experience.

Create a new space so that the Proxy Gateway widget is available. You can do this by creating a new space and page, then adding the Proxy Gateway widget to that page; or by using the Service Administration template:

Go to Manage Spaces > Create Space.

In the Space Name field, enter Proxy Service Administration.

Select the Create a new space using a template check box. Select the Service Administration template from the menu. Click Save. You are returned to the Space Manager page.

Click the Proxy Service Administration Space link.

Select Proxy Gateway. The Proxy Gateway section includes the EAIProxyGatewaywidget. This widget shows the associations between a Proxy Gateway and Proxy Group.

Our first task is to associate a service provider with the Proxy Group, and create and expose a virtual service on the Proxy Gateway:

Click the EAIProxyGatewayProxyGroup row and select the pencil icon at the end of that row.

The Proxy Group view is displayed and all the associated services are listed. Ensure you have deployed the EAI_AccountService file.

In the WSDL Location field, enter http://localhost:9081/EAI_AccountServiceWeb/sca/AccountServiceExport1?wsdl

Click Add Service.

The WSDL will be processed by WebSphere ESB runtime and a subset of the information is displayed, as shown in below figure. Select the Enable Virtual Service check box and click Save.

The widget shows the one virtual service deployed within the Proxy Group.

Test the application:

When we have completed the steps to configure your settings in Business Space, requests can be routed and resolved WSDLs can be returned. This section shows the mechanism of testing the Proxy Gateway using the Web Service Explorer within WebSphere Integration Developer:

In WebSphere Integration Developer, go to Window > Open Perspective > Other > Web.

To start the Web Services Explorer, click Run > Launch Web Services Explorer.

Select the WSDL page icon as shown in below figure.

Click WSDL Main Link. The WSDL page loads.

Enter in the WSDL URL field: 
http://localhost:9081/EAIProxyGateway_GatewayWeb/sca/
EAIProxyGateway_GatewayExport_WS_SOAP11/AccountServiceExport1_AccountServiceHttpService?wsdl,

and click Go. This loads the WSDL into the Web Service Explorer.

Click the getAccountDetails operation. Enter a value for the account number and click Go. The expected result is shown below:

Conclusion

This article introduced you to the proxy gateway pattern, which provides a Web service gateway that is fast to build and meets the majority of requirements with an out of the box experience. The article started with an overview of service gateway patterns and then went into detail on the architecture of a proxy gateway. It showed you how the built-in configuration store is administered using Business Space. The development tools provided, specifically the Patterns Explorer used to generate a proxy gateway implementation, was described. An end-to-end example showed you how to build, configure, and test a proxy gateway. 

Downloads

File Name	Description	Size	Download
Proxy Gateway.zip	Proxy Gateway Sample	32 KB	Download
Service Gateway in IBM WESB.pdf	Service Gateway in IBM WESB Document	635 KB	Download

continue reading

Clearing the Java class caches in IBM WAS, WPS & WESB

Abstract:

Instructions on clearing the java class caches in IBM WebSphere Application Server, WPS & WESB. The JVM's shared class cache and WebSphere Application Server's, WebSphere Process Server and WESB OSGi class cache.

Resolution:

The main reason behind cleaning caches is to delete old class references which have been taken the WebSphere Servers. After an upgrade, it is possible that the class caches are still holding onto previous versions of classes. It is also possible that the caches became corrupted. The best practice to keep our server with updated classes is to clean caches after upgrade of applications.

We need to clean two caches, the JVM's cache and the OSGi cache. The server has to be stopped before clearing the cache.

To clear the OSGi class cache:

For UNIX platforms, run the following script in each profile:

<WebSphere_HOME>/profiles/profile_name/bin/osgiCfgInit.sh

Example:

WAS: /app/wasv7/profiles/was01/bin/osgiCfgInit.sh

WPS: /app/wpsv7/profiles/wps01/bin/osgiCfgInit.sh

WESB: /app/wesbv7/profiles/wesb01/bin/osgiCfgInit.sh

For Windows platforms, run the following script in each profile:

<WebSphere_HOME>\profiles\profile_name\bin\osgiCfgInit.bat

Example:

WAS: C:\IBM\WebSphere\AppServer\bin\osgiCfgInit.bat

WPS: C:\IBM\WID7_WTE\runtimes\bi_v7\profiles\qwps\bin\osgiCfgInit.bat

WESB: C:\IBM\WID7_WTE\runtimes\bi_v7\profiles\qesb\bin\osgiCfgInit.bat

To clear the JVM class cache:

For UNIX platforms, run the following script in each profile:

<WebSphere_HOME>/bin/clearClassCache.sh

Example:

WAS: /app/wasv7/profiles/AppServer/bin/clearClassCache.sh

WPS: /app/wpsv7/profiles/wps01/bin/clearClassCache.sh

WESB: /app/wesbv7/profiles/wesb01/bin/clearClassCache.sh

For Windows platforms, run the following script:

<WebSphere_HOME>\bin\clearClassCache.bat

Example:

WAS: C:\IBM\WebSphere\AppServer\bin\clearClassCache.bat

WPS: C:\IBM\WID7_WTE\runtimes\bi_v7\profiles\qwps\bin\clearClassCache.bat

WESB: C:\IBM\WID7_WTE\runtimes\bi_v7\profiles\qesb\bin\clearClassCache.bat

And clear the following directory contents:

<WinUsers_home>\Local Settings\ApplicationData\javasharedresources\

Where WinUsers_home is either C:\Documents and Settings\DefaultUserOR C:\Users depending on your current version of Windows.

continue reading

Localizing a Coach View using IBM BPM V8.0

Introduction

Localization, the process of adapting a product or services to a particular language or culture, is available within Business Process Manager. The primary use case for localization is to translate coaches, coach views, and aspects of user interfaces into other languages while still maintaining the original variable structure within the coach view. When we want to display our front end to end users it will be English user interface by default. By using localization concept in IBM BPM V8.0, we can make our user interface effectively to support multiple languages.

Overview

Here By using localization concept in IBM BPM V8.0, we can make our user interface effectively to support multiple languages. The basic idea about the localizing coach views is to make end users comfort with their local language. Here I am going to explain how we can create a Coach view and how we can make localization of the coach view.

In this example, the Coach View has English labels. The default locale in this case is English. However, you want French-speaking users to be able to read these labels by providing translations.

We will take a Bank application where bank is providing online credit card application to apply credit card online for the customers. When the customer from US, they can see English language as default in front end (Online application). When the customer is from France he should see the online application form in French language.  This credit card application form we are going to develop and making localizing using coach views in IBM BPM V8.0.

Implementation

We need to complete the following steps to build our application.

Ø  Create and Implement a Coach View.

Ø  Create a localization Service.

Ø  Configure Localization Service with Coach View.

Ø  Create Human Service and Implement.

Ø  Test the application.

Create a process App in IBM Process Designer and name it as ‘BANK APPLICATION’. Open the BANK APPLICATION in Process designer.

Create and Implement a Coach View:

First, we need to create coach view. Click the + next to User Interface and select Coach View to create a new Coach view.

Name as ‘Credit Card Application’. Drag and drop Vertical Section control into Layout panel rename as ‘Credit Card Application’.

Add the text controls and rename as Applicant Name, Account Number, Pan Card Number, Email ID, Phone Number, Income, and Company, add Date picker control rename as Date Of Birth, and add button Control rename as Submit to the Coach View and build as shown below.

Create a localization Service:

Now we want to create the localization resource for the local. Click on the + sign select Localization Resource and rename as LocalizationResource.

Under localization keys, we need to add the keys. Some preferred suggestions for naming conventions include lower camel case or all caps to represent a constant value. Type a Key name and click on Add.

Add the all keys which are required for your application.

Next, add all of the languages that are desired for the labels to be converted into other languages under Localization section.

Under Localizations click on add and select the France.

Click the value for the default locale and type value. To save this value and move to the French locale, press Ctrl+Enter. Type French Value then press Alt+Enter.

Repeat the previous step and this step for the other keys.

Table 1. Values for the keys
Key	Default value	French value
AccountNo	Account Number	Numéro de compte
ApplicantName	Applicant Name	Nom du demandeur
Company	Company	entreprise
CreditCardApplication	Credit Card Application	Demande de carte de crédit
DateOfBirth	Date Of Birth	Date de naissance
EmailID	Email ID	email ID
Income	Income	Revenu
PanCardNo	Pan Card Number	Pan Numéro de la carte
Phone No	Phone Number	Numéro de téléphone
Submit	Submit	Soumettre

Save the changes to the localization resource. Select the French and add the values to key under localization values.

For Default Locale add the English labels which we want show on coach view.

Configure Localization Service with Coach View:

Next, go to the coach that we would like to use the localization keys on.

First, in the Variables tab, add the Localization Bundle Group as a LocalizationResource.

Under variables section in Coach View, click on + sign beside Localization Resource and select LocalizationResource.

Now it will look like below.

Then, on the Coach View, choose the label variable symbol, hit the Select button, and within LocalizationResource, bind the correct localization key to the label.

Replace the existing labels with the appropriate keys from the localization resource:

Change to the Layout page and select the ApplicationName field. In the General properties, click the   button for the label. In the window that opens, expand the Localization Resources nodes to select the ApplicationNamekey.

Repeat the previous step to assign the appropriate keys to the other fields in the Coach View.  Final coach view will look like below.

Create Human Service and Implement:

Now we need to create and implement Human service to run our application.

Click the + next to User Interface and select Human Service to create a new Human Service and rename as Credit card HS.

Drag and Drop Coach Activity and rename as ‘Credit card Application’.

Select Coaches section in Credit Card HS, drag and drop Credit Card Application Coach View from No Tags Controls.

Come back to Diagram section in Credit Card HS human service select wire control and wire as shown below.

Save the changes.

Test the application:

Now we have completed our application development. We need to test either this application is working as expected or not. First we will test as a default language English is displaying or not.

Open Credit Card HS Human Service and click on Run Service button at right corner.

Now our application will open in a browser, it will be look like below.

The above user interface is understandable for English users; we need to show the user interface in French language for French users. So log into Process Admin Console and change the language.

Click on Preferences at right corner select French language, then logout and login the console.

Now come back to Credit Card HS human service and click on Run Service button. Now in browser our application page will open in French language as shown below.

So the above user interface is clear for French users. This is the way we can implement localization for different language support in Coach View.

Conclusion

Localization, the process of adapting a product or services to a particular language or culture, is available within Business Process Manager. The primary use case for localization is to translate coaches, coach views, and aspects of user interfaces into other languages while still maintaining the original variable structure within the coach view.

Downloads

File Name	Description	Size	Download
BANK_APPLICATON_V1.0.twx	Localization Sample	780 KB	Download
Localizing a Coach View.pdf	Localizing a Coach View Document	760 KB	Download

continue reading