I’m delighted to read that require is now included in Dojo 1.7 (at least in the beta form).  Here is an example of why – to write some code, you just create a JavaScript file, name it “math.js” with the following:

	require([ "dojo" ], function (d) {
		console.debug(d.version); // todo: proper math here
	});
Then in another JavaScript file in the same folder:

	require([ "./math" ], function (m) {
		console.debug("loaded");
	});

Console shows the version details and then “loaded”.  Like magic. There is no need for any hardcoded namespacing or hairy module paths. Pretty cool huh?  (If you’re not a web developer, then this probably won’t :-))

I saw a tweet from @dalmaer that HTML5 Boilerplate was nearing its first release and decided to challenge myself to setting up a “Hello World” website with all the essential basics in 120 seconds (I did not – I actually fell over at the first hurdle with file permissions).

 

Here’s how – on Mac…

  1. download HTML5 Boilerplate 5 from http://html5boilerplate.com
  2. start the timer
  3. extract the zip into web documents folder, e.g., /Library/WebServer/Documents/h5bp
  4. edit the index.html to include the following code just above the jQuery load (seemed appropriate):<script src=”http://ajax.googleapis.com/ajax/libs/dojo/1.5/dojo/dojo.xd.js”></script&gt;
    <script>
    dojo.ready(function () {
    var div = dojo.create(“div”, { innerHTML: “Hello World” }, dojo.body());
    dojo.animateProperty({ node: div, properties: { fontSize: { end: 300, units:”pt” } }, duration: 1000 } ).play();
    });
    </script>
  5. stop the timer (and start web browser, go to the folder’s location, e.g.,  http://localhost/h5bp)

… on a more serious note, HTML5 Boilerplate is nice and handy for those who want to get setup in 120 seconds.   Will HTML5 Boilerplate add Dojo loader alongside jQuery for the release?

There are times when I like to have a separation of content and presentation in my iWidgets, with the presentation defined through style sheets.

JavaScript Code

Here’s a quick summary on one method of achieving this with iWidgets:

In the “onLoad” method, which is the default method with iWidget that is called upon creation of iWidget, use something like the following:


try {
	dojo.registerModulePath("com.ibm.issw.iwidgetdemo", this.iContext.io.rewriteURI("."));
	var url = dojo.moduleUrl("com.ibm.issw.iwidgetdemo", "HelloWorld.css");
this.loadStyleSheet(url);
} catch (exp) {
	console.debug("onLoad's thrown exception. Exception: " + exp);
}

with the loadStyleSheet function like the following:


loadStyleSheet: function(url) {
	var file = document.createElement('link');
	file.setAttribute("rel", "stylesheet");
	file.setAttribute("type", "text/css");
	file.setAttribute("href", url);
	document.getElementsByTagName("head")[0].appendChild(file);
}

Note

If multiple instances of this iWidget are deployed on the same page, then there may be implications of the style sheet being loaded more than once.  This can be addressed by adding code to loadStyleSheet to check whether the stylesheet has already been loaded.

Style Sheet Editor

WebSphere Integration Developer has a nice CSS editor:

Two panes, on the left result examples are shown, including the currently selected=

A summary of my iWidget development in the classic “Hello World” format.

Requirements

1. WebSphere Integration Developer 7;
2. a deployed Business Space 7 (in my case, on WebSphere Portal 6.1.5)
3. a supported Mozilla Firefox (3.0.x with 7.0.0.0 of Business Space) or Internet Explorer 6 (SP2) and 7

Develop iWidget

Bring up WebSphere Integration Developer and get on the “Web” perspective.  Ask to create a new “Dynamic Web Project”.

Dynamic Web Project dialog, project name set to com.ibm.issw.iwidgetdemo, target runtime set to WebSphere Process Server v7.0, Dynamic Web Module version is set to 2.5, and configuration is custom. EAR membership is unticked.
EAR or WAR?  If EAR, say yes to “Add project to an EAR” – if WAR, say no.  For iWidgets, I would use WAR’s.

Modify the configuration to include the iWidget facet:

iWidget ticked

When the project has been created, create a new iWidget:

iWidget project wizard selected
and…

Create a New iWidget dialog. iWidget name set to HelloWorld.xml, source folder to /com.ibm.issw.iwidgetdemo/WebContent, and type set to Simple Widget. Edit mode is unticked.

The iWidget editor should then appear.  A good opportunity to explore.  When you’ve done – there’s nothing that needs to be done here if all what you want to see is a “Hello World” iWidget.

Test iWidget

With the iWidget file selected, Run -> Run As -> Run on Server, and ask for the J2EE Preview server:

J2EE Server is selected

Then the iWidget should be automatically run in a testing environment for iWidgets.  I prefer to use Firefox and Firebug which can be configured through Preferences -> General -> Web Browser (use the Search… button to find Firefox executable):

Web Browser pane. Use external Web browser is selected, under the External Web browsers list, Firefox with Firebug is ticked. The two other, unticked options are Default system Web browser and Internet Explorer.

and the iWidget should show in Firefox:

Firefox with one window, of 3 parts: 1. HelloWorld widget showing "Hello World", 2. three widgets for creating, sending, and receiving events, all blank, 3. the FIrebug console, currently showing content of iWidget in the CDATA tag, and some text saying there are 4 errors.

The wiring aspect of the iWidget can also be tested through using the widgets in the middle (currently blank as the iWidget has no configured events).

Deploy iWidget

A couple of jobs here.  Firstly, export the project as WAR (or EAR) and deploy on the JEE-based server, steps of which can be found elsewhere.  Secondly, business Space’s palette needs to be updated with details of this iWidget:

A couple of artificets need to be produced to update the palette.  Create a new general project with the following structure:

Project folder called com.ibm.issw.bspace.catalog, with two folders called catalog and endpoints, in catalog a file called catalog_ISSW.xml and in endpoints a file called ISSWEndpoints.xml

with contents for the catalog file based on this and for the endpoints file on this.

Export the project as ZIP and deploy on Business Space.  The installBusinessSpaceWidgets for standalone Business Space and installBusinessSpaceWidgetsOnPortal for Business Space on Portal commands can be used to deploy.  For example, for on Portal:

/opt/IBM/WebSphere/wp_profile/bin/wsadmin.sh -conntype NONE

$AdminTask installBusinessSpaceWidgetsOnPortal {-serverName WebSphere_Portal -nodeName vm304 -widgets /home/bjfletcher/ISSWCatalog.zip}

Reload Business Space in the web browser and the widget should appear in the palette.

Thanks

Thanks to E. Wayne and V. Ramamoorthy – particularly updating Business Space’s palette on Portal.

Introduction

Business processes that are developed for WebSphere Process Server (or, in my case, WebSphere Dynamic Process Edition), often involve what is known as “Human Tasks” – steps for the mankind.

Human Tasks can be executed through the web browser, e.g., by filling in a form.  They are often presented through what is known as “iWidgets” deployed to a mashup portal called “Business Space”.  The iWidgets and Business Space are linked to the Process Server backend using RESTful API’s.

A scenario may be where the Process Server and Business Space are deployed to two separate servers – in my case, Business Space is deployed on WebSphere Portal, which is separate to the Process Server:

Business Space is within WebSphere Portal, user's Mozilla Firefox connects to this, and a separate WebSphere Process Server
A properly configured Portal would use the remote Process Server for Human Tasks stuff through their RESTful API’s which is explained on the Information Center.

If the Human Tasks use web forms then there is however one more step that needs to be performed.

Problem

When a Human Task is brought up, for example, in the Task Information widget, a 404 error will show – that the form could not be found.  The problem here is that the web projects are deployed as part of their enterprise applications on the Process Server, rather than on the Portal.

Solution

What can be done is to deploy the web applications separately to the Portal.  Here’s how…

1. Get the WAR files

Bring up WebSphere Integration Developer (or a JEE-based tooling), switch to the “Web” perspective, and the web projects should appear in the “Enterprise Explorer” list – usually their names end with “web”.  Look in the “WebContentt” of each project to see what forms there are – if there are, export the web project as a WAR file.

2. Find out the Context Roots

In each of the web projects, open the “Deployment Descriptor”.  In the “Overview” tab, on the right, under “Usage”, there should be text saying “The following Enterprise Applications use this web module” – click on the link that is shown as the enterprise application using this web module.

In the “Deployment Descriptor” of the enterprise application, switch to the “Module” tab from “Overview”, under “Modules” list, select the web module that we’ve exported, and on the right, there is the “Context root” field, which we would want to take note of.

Repeat for the other web projects.

3. Install WAR files to Portal set to their Context Roots

The WAR files can be installed through Portal’s WebSphere Application Server console the usual way – using the WAR from Step 1 above and the Context Root from Step 2.

The "local file system" has been navigated to the WAR file and the Context Root field is set to MortgageApplicationWeb

and, with the common standalone Portal deployment, don’t forget to change from server1 to WebSphere_Portal in the “Map modules to servers” step of the WAR installation process.

Map modules to servers page, where Server has been changed to WebSphere_Portal from server1
Restart Portal.

Thanks

Thanks to T. Schulze for his contribution to this method.

Working with a WebSphere Application Server-based solution that is deployed remotely on a Linux platform, such as in the cloud, with the Rational Application Developer-based tooling, is a popular requirement.  In my case, the remote server was the WebSphere Dynamic Process Edition (WebSphere Process Server with a set of products including WebSphere Business Monitor) on RHEL, and WebSphere Integration Developer (WID).

It worked bearing in mind the following points:

1. if the remote server is shown as “Stopped” even though it is started, and the remote server is on a Linux platform, apply RAD/WID patch included in PMR 59591,L6Q,000 (as of 7.0.1.1 this patch is still needed), substitute the jar of same name with PMR’s attached jar, and rename this jar to be the same as the substituted one;

2. confirm that the server isn’t ND (Network Deployment) as this is not supported for remote uses from the RAD/WID;

(reference: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14253319)

3. deployment will fail if host name returned from remote server is not recognised by RAD/WID machine, look at what host name is used by the server by checking <WAS_HOME>\profiles\<PROFILENAME>\config\cells\<CELLNAME>\nodes\<NODENAME>\serverindex.xm – and adding the host name to hosts file on RAD/WID machine with the IP address of the server, for example – the host name in serverindex.xml in my case was “pear”, so I added “123.45.67.89 pear” (123.45.67.89 is the IP address of the server) to the hosts file.

(reference: https://www.ibm.com/developerworks/forums/thread.jspa?messageID=13926131&#13926131)

I had a set of applications deployed on a Process Server however they would not start as a remote server – a MQ server – was behind a firewall and was inaccessible.  This firewall allowed the SSH port (23) however, so, naturally, I employed SSH tunnelling.

I used a technique to avoid having to modify the applications to use localhost as the hostname in order to direct traffic to go via SSH tunnel instead of directly to the firewalled MQ server.  In /etc/hosts, I added “vm123.developer.ihost.com” (the MQ server) to the “127.0.0.1″ line.  This would trick the applications into using 127.0.0.1 for the MQ server.  The SSH tunnel command needed changing however to use IP address instead of the host name, for example:

ssh -f bjfletcher@vm123.developer.ihost.com -L 1414:vm123.developer.ihost.com:1414 -N

to:

ssh -f bjfletcher@123.45.67.89 -L 1414:123.45.67.89:1414 -N

This was to use the actual MQ server through the IP address for the SSH tunnel whereas the applications would use the SSH tunnel itself through the host name.  Nice and easy huh? :-)

In my current engagement, a question sometimes comes up regarding data in the mashup database (e.g., of the catalog that Business Space for WebSphere uses).  There is a nice spreadsheet that explains in detail the database schema used, which is titled “Lotus Mashup Schema Data Dictionary (Basis: v2.0.0) and is located dbscripts/BusinessSpace/lotus_mashup_db_dictionary.xls in the WebSphere Process Dynamic Edition installation media.

I had a requirement for WebSphere Portal 6.1.5 on WebSphere Process Server 7 (a common scenario) and so I tried this on 64-bit Ubuntu 9.10.

It just worked. The following should help for a quick non-supervisor development environment with no need to perform platform tweaking.

Preparation

Increase the maximum number of files that can be open to 10240 or bigger (or else WebSphere Portal installation will fail):

echo “bjfletcher hard nofile 10240″ >> /etc/security/limits.conf
echo “limit -n 10240″ >> ~/.profile

Remove AppArmor (or else there may be some security issues, unnecessary for a development environment):

/etc/init.d/apparmor stop
update-rc.d -f apparmor remove

WebSphere Process Server 7

To install:

IM/userinst

During the installation, ask to be installed non-root/supervisor.  Ask for Samples and the WPS profile to be created if desired.  The Installation Vertification should succeed.

WebSphere Portal 6.1.5

To install, on the “IL-Setup” media:

dist/linwpinstall

and, during the installation, ask to:

  • install on top of an existing WebSphere Application Server (the one installed by WebSphere Process Server)
  • change default location from /opt/IBM/WebSphere to /home/bjfletcher/IBM/WebSphere (as non-supervisor installation)
  • change host to bjfletcher-vmware.ibm.com (else comes the error: “EJPIC0067E: WebSphere Portal and Lotus Content Management requires a fully-qualified host name that is recognized by the DNS Server. Short names, loopback addresses, IP addresses and illegal characters such as blanks are not allowed. Enter the host name again”)
  • separately, append bjfletcher-vmware.ibm.com to the 127.0.1.1 line in /etc/hosts (for a fully qualified host that is also DNS-able)

The installation asked to supply paths to the 5 different installation folders. Installation uses names like “IL-3″, here’s the mapping to download codes:

  • IL-Setup > CZ8G7ML
  • IL-3 > CZ8I4ML
  • IL-4 > CZ8I5ML
  • IL-5 > CZ8I6ML
  • IL-5A > CZ8I7ML

Understand that the 5th final step takes a long time.

It all worked.  The usual preparation steps (under “Preparation”) apply.  In a previous attempt, the 5th final step of the installation failed – the media was on a path containing spaces (in my experience, this is a common reason with IBM middleware software).

Ben

WebSphere Integration Developer 7.0, there is a single media for Windows and Linux.

It worked great on 64-bit Ubuntu 9.10. Some notes:

The installation files must be in a folder whose path doesn’t contain any spaces. See the Technote regarding this.

To install as non-supervisor (my preference for my personal environment) simply run:

disk1/IM_linux/userinst

This will suggest installing IBM Installation Manager (if not installed already with another product) to:

/home/bjfletcher/IBM/InstallationManager/eclipse

and IBM WebSphere Integration Developer to:

/home/bjfletcher/IBM/WID7

where bjfletcher is my system username. See this page, which is also referred to by the launchpad application, regarding non-supervisor installation.

I didn’t need a Java Runtime Environment (JRE) as the installation used its bundled JRE.

To test, I asked the installer to install every package that was offered. All installed fine.

The installer added launchers to the Applications menu on the Ubuntu desktop – one for IBM Installation Manager if not installed before, and one for WebSphere Integration Developer.

It all worked great. No issues. There are some general 64-bit Ubuntu 9.10 changes (the “Preparation” section) and Eclipse 3.4.2 fixes that should be in place (e.g., to fix user interface issues).

Updating to 7.0.0.1

I updated to 7.0.0.1 (consult the list for what fixes it has) using IBM Installation Manager’s updates facility. There was an issue during the prerequisite stage where it complained that libstdc++.so.5 wasn’t in the system library path. The solution I used was to make the library visible on /usr/lib (which is actually /usr/lib64) as well as /usr/lib32:

sudo ln -s /usr/lib32/libstdc++.so.5 /usr/lib/libstdc++.so.5

and then click “Recheck Status”. The complaint went and WebSphere Integration Developer was updated with 124 MB worth of downloads to 7.0.0.1.

Ben

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 4 other followers

Author

I work in IBM Software Services for WebSphere and Lotus (ISSW and ISSL respectively), who do specialist work for customers. Contact ISSW or ISSL for more details. I can also be contacted through email. Any views here are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Follow

Get every new post delivered to your Inbox.