Tuesday, September 7, 2010

City of Largo, FL Wins With Panther Again

The City of Largos’ Recreation Department received rave reviews from users when they went live in mid August 2010. The Recreation application, which was built with Panther5.20/Oracle/Linux, is an accounting, management and tracking system, allowing the department employees to manage their daily duties in an effective way.

For the past 12 years, the city has utilized Prolifics’ legacy tools to build applications for their Police and Recreation Department, starting with JAM7 on SCO. With the release of Panther 5.0 for Linux several years ago, the city migrated most of their applications off their SCO platform. A reason for staying with Panther was its portability; i.e. ability to run on most platforms and to connect to heterogeneous databases with minimal changes.

In recent months, the city’s development team has been thrilled at enhancements made to the Panther Linux product, which include support for anti-aliased fonts, image and text support for tab cards and enhancements to tooltips.

The city’s next project is to web-enable the Recreation app, allowing citizens to register for classes being offered by the department.

According to their Developer/Administrator, “... I cannot over emphasize the effect that the upgraded Panther features have had with both the Recreation Department and City as a whole. We've been able to provide tools with a modern look and feel and in many cases, better than what we could buy at comparative costs.”

Sample screen shots from the Recreation Application






To see the customer's take on this solution, read Dave Richards' entry about Panther on the City of Largo Work Blog

Amrith Kaur-Maldonado, first joined Prolifics as a Consultant and then moved into the Prolifics Education Dept as a JAM/Panther trainer. She has experience in conducting WebSphere Developer Training at IBM training facilities. Amrith then transitioned back into the Technical Support Team 7 years ago and she now managers the Support Team.

TAM ESSO in the wild: A look at ISO-NE's implementation

Christopher Ehrsam, Senior Security Consultant

I recently was involved in a unique implementation of IBM Tivoli Access Manager for Enterprise Single Sign On (TAM ESSO), working with ISO-NE, a major utility company, towards increased security and monitoring performance. Operating in a 24/7 environment, ISO machines must be highly available and employees monitor the health of the power grids in control room using a number of shared workstations. The company is required to track which users log into each workstation and must lock machines that were not being worked on. Doing so complies with Critical Infrastructure Protection (CIP) government standards and enables system notifications for user activity on any workstation. The new system integrates the existing building badges and unique user IDs making two- factor authentication possible.

As we were planning this project, we knew how significant time would be with ISO. Summer is considered a “high risk season” in this industry because of the increased utility usage during these months and the company’s infrastructure must be prepared to handle the activity. We realized the importance of preparing the company’s infrastructure as quickly and efficiently as possible. Prolifics focused this implementation around ISO’s specific security and monitoring desires, which puts them at an advantage with the badge reader and centralized auditing capabilities.

For those of you who are interested in hearing more, I will be speaking at Prolifics’ TAM ESSO live Webinar on September 15 to discuss the solution’s implementation and success. The webinar will include a demonstration showing how TAM ESSO can increase enterprise security, provide application access tracking, and increase your ROI.

Christopher Ehrsam is a Senior Security Consultant with Prolifics. Chris has been in the Identity Management field for over 10 years, getting his experience working with the Tivoli product family at IBM.

Wednesday, August 25, 2010

Integrating with Salesforce.com

Salesforce.com (aka Salesforce) is the most commonly used cloud-based Software as a Service platform for Customer Relationship Management (CRM). Recently, we have been involved with a lot of customers who are planning to start migrating to or have made a strategic decision to use Salesforce to manage their customer contacts, track sales orders, streamline their sales processes, etc. In fact, Prolifics itself is a Salesforce customer.

Our own experiences, and those with our customers who use Salesforce, have given us an in-depth understanding of what it takes to ensure that this CRM solution is made universally available within the enterprise – to business processes that require customer information or to portal applications that mash up customer information with data from other systems. This blog entry details three patterns that we have commonly used when integrating with Salesforce and that we believe can be reused – entirely at the design level and to a good extent at the implementation level.

1. Enterprise CRM Services – Every enterprise has defined standards when it comes to their enterprise services and data formats. The reusable enterprise services are exposed via the ESB and all the end applications use these enterprise services to communicate with end systems so that the ESB can provide the common functionality and the governance needed when performing system integration. Using this same concept when working with Salesforce allows enterprises to centralize the Salesforce integration at the ESB layer (the ESB communicates with Salesforce using SOAP/HTTP web services), do transformation, security, etc. at one common place and provide clients – processes, portals or mashups, etc. – with the consistent enterprise-wide data representation to which they are accustomed. The enterprise services provide the generic CRM interface to the clients, so that if the CRM system has to be changed, the hundreds of clients that use the CRM system in the enterprise do not have to change. The IBM WebSphere Enterprise Service Bus is commonly used for implementing this pattern.


2. Publish CRM Data – Another common requirement is to ensure that CRM data is passed from Salesforce to back end systems based upon changes that happen within Salesforce to this information. The ESB provides a service (SOAP/HTTP web service) that gets invoked by Salesforce (with all the relevant information from Salesforce) when data of interest changes in Salesforce. This data is then transformed and passed to the back end systems. The benefits of this approach include a centralized service definition on the ESB, transformation of data, centralized security management, supporting legacy applications that are not web service enabled [but still need CRM data], etc. The IBM WebSphere Enterprise Service Bus or IBM WebSphere Message Broker is commonly used for implementing this pattern. [Note: the reverse flow from end systems to Salesforce is handled similarly, instead of being invoked by Salesforce; the ESB invokes a service on Salesforce.]

3. Bulk Load of CRM data – It is very typical for customers to need the ability to bulk load customer data from their existing homegrown systems into Salesforce. These kinds of requirements are also common when mergers and acquisitions happen and new customer data needs to be loaded. During the bulk load of CRM data, there may also be a need to cleanse the information before loading it into Salesforce. The IBM InfoSphere DataStage, IBM InfoSphere QualityStage, and the IBM InfoSphere Information Server Pack for Salesforce.com together support this pattern that involves the definition of ETL jobs that extract data from different sources, cleanse, map the data to Salesforce format, and load it into Salesforce.


I want to conclude by saying that we at Prolifics believe in “eating our own dog food.” Prolifics has a production implementation of IBM WebSphere Enterprise Service Bus that was built using the pattern described above (Publish CRM Data) that enables the data we have in our Salesforce instance to be published to IBM’s Global Partner Portal based on Siebel.

In my next set of blog entries, I will focus on couple of related topics:

  • IBM’s acquisition of Cast Iron Systems and how the solution supports these patterns of integrating with Salesforce

  • A set of assets that we are currently working on at Prolifics to help customers jump start their own Salesforce integration initiatives.

Rajiv Ramachandran first joined Prolifics as a Consultant, and is currently the Practice Director for Enterprise Integration. He has 11 years experience in the IT field — 3 of those years at IBM working as a developer at its Object Technology Group and its Component Technology Competency Center in Bangalore. He was then an Architect implementing IBM WebSphere Solutions at Fireman’s Fund Insurance. Currently, he specializes in SOA and IBM’s SOA-related technologies and products. An author at the IBM developerWorks community, Rajiv has been a presenter at IMPACT and IBM's WebSphere Services Technical Conference.

Monday, August 9, 2010

Mobile Portal – Creating A Simple Mobile Portlet - Part III

Samuel Sharaf, Solution Director, West Coast

Part 3 of this blog series takes you through series of steps to demonstrate the creation, development and deployment of a simple Mobile Portlet using Rational Application Developer. While working on this blog I found out that this could be a long one with all the images/screenshots. So this first entry just focuses on pre requisites, creating a Mobile Portlet project and exploring the project artifacts.

Before you get started, please download and install the following software images on your machine:
  1. Rational Application Developer 7.5.1
  2. WebSphere Portal 6.1.x
  3. Mobile Portal Toolkit 6.1

Step – 1 Create a new Project
Start Rational application developer, hereafter called RAD, you can use either an existing workspace, or create a new workspace.



Create a new Portlet Project and name it MobilePortlet, set runtime to WebSphere Portal 6.1. Set the Portlet Type to JSR 286. Set the Portlet type to Mobile Portlet and click Next.



Once the project is created, the workspace looks like the figure below:


Note that a new Portlet has been created in the com.ibm.mobileportlet package in the Java Resource:src directory. Lets review the WebContent folder, the key folders under that directory are:
  1. _MobilePortlet and mcs-policies
  2. Within _MobilePortlet there are two folders called html and xdime. These two folders contain JSP files with the same names (MobilePortletView.jsp)

Note that if the request comes from the web browser, the MobilePortletView.jsp under the html folder gets rendered; however, if the request is from the mobile device MobilePortletView.jsp under the xdime folder gets rendered.

The mcs-policies will hold the device-dependent aspects of the mobile portal e.g. policies for various layouts, themes, components and assets etc. A sample layout file has been created by RAD.

In the next part of this blog series, we will start creating the code artifacts.

Stay tuned…

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

Wednesday, August 4, 2010

2010 Portal Excellence Conference

Samuel Sharaf, Solution Director, West Coast

This year the IBM Portal Excellence conference was held in Hilton Chicago. I was there with one of our key clients (American Express Corporate Travel) to co-present on the solution Prolifics developed. For those of you who are familiar with the IBM world, there is a conference every year for each of the five main brands. For me, this one was nearest and dearest to my heart as I have been involved with IBM Portal technology for several years.

So let’s go over some of the key highlights of the conference…
  • Portal and LWCM 7.0 will be officially released around mid September time frame this year
  • IBM acquired Coremetrics (http://www-01.ibm.com/software/websphere/announcement061510.html)
    The plan is to integrate Coremetrics with the WebSphere platform and exposed the web metrics through out of box Portlets so that organizations can make intelligent business decisions.
  • Project NorthStar was announced, which reflects IBM’s vision and multi-year roadmap for how organizations can create next-generation online experiences. (http://www-01.ibm.com/software/info/northstar/)

Since I am intimately involved on daily basis interacting with the clients, the announcement of Portal 7.0 coming out soon was big news. Besides supporting JSR 286 and Web 2.0, Lotus Web Content Management will finally be fully integrated with the WebSphere Portal and will take advantage of Web 2.0 features for authoring and presentation templates. Also, the integration of Coremetrics with the WebSphere platform and the ability for the companies using Portal internally/externally to perform web trending will be huge.

I might sound biased; however, my presentation with American Express was received very well by the attendees. The session was full and we had lot of live interaction via Q&A with the attendees. The presentation was divided into two main parts. Chris, from American Express, talked about the business case and how the solution brought overall value to their business, while I focused on how the Prolifics team helped designed the overall solution and implement it. What drew attendee’s interest was the fact that the solution is scalable to millions of end users and has been rolled out in 22 different languages; and people in all 5 continents are actively using it to book their travel. If you are interested in learning more about the solution we developed for American Express Corporate Travel, our marketing department has done a great job in providing an overview. (http://www.prolifics.com/travel-portal.htm)

Overall I found the conference very informative and hey – where else could you meet the co-author of JSR 168 and JSR 286 (Stefan Hepper) and some key IBM architects one on one?

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

Tuesday, July 20, 2010

IBM Mashup Center

Niral Jhaveri, User Experience Practice Manager

The Web 2.0 world has evolved, and has evolved considerably. It’s no longer about getting data from the universe of information -- but collaborating, publishing, sharing and deriving business intelligence from the data. The landscape of information now consists of smaller fragments of relevant data commonly known as mashups.

So when a bank searches its database for a customer, it no longer expects to get the name of the customer. But instead expects to get back a data grid of all the accounts linked to the customer, a pie chart showing all the different asset holdings (equities, loans etc), a Google map showing the address of the customer and any relevant alerts on the customer account. And that’s not it -- all the information should be seen on a single unified page! Think it’s difficult? With IBM® Mashup Center, you can access the components that you need to create Web 2.0 mashup and application solutions.

What is a Mashup?
Mashups are situational applications which aggregate disparate data. Mashups add a lot of value by associating data elements that are relevant for the users.

With Mashup Center, you can
  • Create situational apps which are reusable assets
  • Facilitate rapid development of dynamic web applications (widgets)
  • Create feeds from numerable data sources
  • Empower business users to create and share mashup applications, widgets, feeds, and services
  • Provide business intelligence by associating the data elements.

The Architecture



Key Components


Catalog: The catalog is a repository. All feed, feed mashup, and widget information is kept in the catalog.

Widget: A widget is a miniature application that is embedded within an HTML page. With a widget, dynamic content is displayed on the page.

Feed: A feed contains XML data. RSS, Atom and XML feeds are available on the Internet. An example of an RSS feed is the top news stories from Yahoo!, available at http://rss.news.yahoo.com/rss/topstories. Feeds in MashupHub can be created using different data sources and then accessed via a URL.

Page: A page is a collection of widgets and other HTML markup that can be displayed in a Web browser. A page can be a mashup application or a regular Web page.



Why should your business use Mashup Center?

Mashup Center is a great tool for rapid assembly of dynamic web applications. The Mashup pages provide a lightweight web solution that combine application and information to solve many different business needs. Around the inter-web there is a fair amount of interest in mashups and many perceive it as better medium.



Mashups provide a user interface to data from variable sources (or feeds) like Web services, enterprise databases, spreadsheets, even BI warehouses like Cognos. Portability is a valuable add-on provided by Mashup Center. Development and product teams can build mashup pages/widgets and easily expose it to any intranet, internet or enterprise portals (even to Microsoft Share point).

With IBM Mashup Center business stakeholders get the freedom to assemble applications that cater to their requirements. Business users can combine, transform and reuse the mashups to create visualizations and provide real-time collaboration.

Mashup wiring enables you to collaborate data for a more unique, dynamic interface. So let’s say for example, a map widget can be wired to several feeds like real estate listing, company address, customer listing, hotels and restaurants. You can also wire the customer listing to its stock prices, relevant market news for the customer etc. You get the idea. Wiring widgets is extremely intuitive and easy to use.

Mashups and WebSphere Portal
Mashups are usually meant for creating applications which are developed in a very short time to target a very specific business problem. It is generally recommended to develop mashups when flexibility and time-to-develop applications is more important than governance and traditional development model provided by WebSphere Portal.

Pre built widgets (like graphs, reports, Google Gadgets) make Mashups more suitable for visualization and aggregation of data from different data sources on a single screen. However for a more transactional based enterprise system, WebSphere Portal is much better suited.

Style of development for portlets and mashups is also different. Widgets can be developed using different tools and have a relatively small and a generic code base. Feeds can be developed visually or by writing native SQL. Developing portlets require a more structured model by incorporating one or more design patterns and/or frameworks (Struts, JSF etc).

WebSphere Portal provides a much broader set of features like Virtual Portal, SSO, Content Management, Collaboration, advanced security model on Pages, Portlets and resources, Portal search, impersonation. These set of features are key differentiators between the WebSphere Portal and Mashup Center.

Mashup applications can run along side or within the portal framework, it all depends on the solution designed. WebSphere Portal 6.1.5 provides the ability to render Mashup Pages and widgets within the portal container. At the same time, Mashup Center can render any Portal page by providing the appropriate URL for that page.

An Example of a Customer Dashboard Mashup


Niral Jhaveri was most recently a Senior Consultant at Prolifics and has extensive expertise in the IBM Lotus, WebSphere and Rational family of products. He has played a key role at several strategic clients by providing technical leadership. Niral has an extensive background in the design and development of IBM WebSphere Portal, SOA and Web 2.0 applications with a proven track record of consulting and architecting solutions for several industry verticals like Finance, Retail, Insurance and Technology.

Wednesday, July 7, 2010

Mobile Portal – Overview, Architecture and Development - Part II



Samuel Sharaf, Solution Director, West Coast

In the first part of this blog series we covered the high level overview of the IBM Mobile Portal Accelerator offering. In this part, we will review the architecture of the IBM Mobile Portal Accelerator, hereafter, called MPA; and explore its key components, their functionality and how the individual components interact in servicing a typical mobile device request.

Let’s dive right into the architecture: figure 1.0 illustrates the key components of MPA. Note that since MPA installs and runs on top of the IBM Websphere Portal Server, I have illustrated MPA components in conjunction with Portal Server key components.


Figure 1.0 – Simplified MPA Architecture

At the heart of MPA architecture is the Multi-Channel Server, hereafter referred to as MCS. The MCS is the runtime component that transforms XML-based Device Independent Markup Extensions (XDIME) into native markup languages for individual devices. MCS uses the built-in MCS Policy Repository to manage a large number of devices such as PDAs, cell phones, smart phones, and other devices.

The MCS Policy Repository is not a single database or a single file; rather, it is a set of policy files managed by MCS. These MCS policy files define the presentation characteristics (layout, component and theme, and so on) of a device. There are a number of policies defined in MCS. Device, layout, theme, and component policies are the most commonly used.
With the combination of these policy sets defined in MCS repository, MPA can support displaying Portlets in varied types of devices, with flexibility to adapt to various layouts and present with different looks and feels, etc.

If you think about it, it’s a very powerful feature. MPA enables you to write once and use these policy sets to display your Portlets in various mobile devices. Compare it to writing mobile specific applications for iPhone, Blackberry, Nokia etc. Time to market for mobile enabling your Portal application is amazingly short.

Another key component of MPA is XDIME aggregator, which extends the existing portal aggregation support to XDIME/XDIME 2. In Part 1, we discussed that XDIME (XML device independent markup extensions) is an extension of XML for mobile devices and is of course device independent.

Having discussed the key architectural components of MPA let’s switch to the run time interaction model, illustrating how these components interact to service a mobile device request.

Figure 2.0 below illustrates MPA run time interaction model:


Figure 2.0 – Run time interaction Model
The numbers in the figure correspond to key steps in a typical MPA scenario:

1. Write the XDIME Portlet or add XDIME JSPs to an existing Portlet.

2. The resulting navigation hierarchy defines nodes (pages, labels, URLs, and Portlets) and extended attributes that specify required device capabilities and type for each node. Navigation nodes and attributes are stored in the Portal Model.

3. When the Portal receives a request from a mobile device, the appropriate markup is determined by comparing the User-Agent string to configured Portal clients. MPA clients are configured with XDIME support, so the portal passes the request to the XDIME Portal Filter. The filter then invokes the XDIME Aggregator to process the request.

4. The XDIME Aggregator queries the Portal model to determine navigation and Portlet availability based on the user and the extended attributes of each node. If the request is for a Portlet node, a PortletRequest object, containing request-specific data, is passed to the Portlet.

5. The Portlet Container invokes the Portlet with the PortletRequest. XDIME Portlets render their content in XDIME and return the content to the aggregator via a PortletResponse object.

6. Aggregated XDIME markup for the requested navigation or Portlet is returned to the Portal Filter, which passes it to the Multi-Channel Server. MCS transforms the XDIME content to device-specific markup by matching it with policies in the repository of Mobile Device Profiles.

7. The Portal Filter inserts the device-specific content in the ServletResponse object for delivery to the mobile device.

The above defined interaction model is simplified and doesn’t go into intricate details. If you would like to read more about it, please refer to the IBM Mobile Portal Accelerator info center (http://publib.boulder.ibm.com/infocenter/mpadoc/v6r1m0/index.jsp).

In the next part of this blog series, we will use the MPA toolkit to create a simple Portlet. Get ready to put your developer’s hat on!

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

Friday, June 18, 2010

Mobile Portal – Overview, Architecture and Development

Samuel Sharaf, Solution Director, West Coast

This is a three part blog series on IBM Mobile Portal Accelerator. The blog series is targeted toward architects and engineers who are looking to get an overview of the Mobile Portal accelerator offering and want to get a simplified understanding of how they can architect and develop Mobile Portal solutions.

Mobile Portal Overview
We live in a world where the usage of Mobile applications is growing exponentially. People need access to information and services wherever they are using whatever devices they have. This can include someone using an iPhone at an Internet café, a BlackBerry at the airport, or a Droid to find the nearest restaurant while on a business trip. The possibilities are almost limitless.

IBM being a key player in the middleware market realized this upward mobility trend and started offering IBM WebSphere Everyplace Mobile Portal framework for developing mobile-enabled applications. This framework evolved in the last few years to support development of Mobile applications for a broad range of mobile devices and providing customized mobile access to Portal solutions. This framework solution is now offered as IBM Portal Accelerator and works in conjunction with the IBM WebSphere Portal software offering. In part 2 of this blog series we will go into details of the overall architecture.

In this part we will focus on the key capabilities and functionalities of the IBM Mobile Portal accelerator framework. So what’s a simple definition of Mobile Portal Accelerator? Put simply, Mobile Portal Accelerator, as an extension of WebSphere Portal, provides a delivery platform that supports aggregation of content and services from both internal and outsourced providers. Architecturally, it provides a framework that can be used to create device independent Portlet applications (XDIME Portlets).

Portal Accelerator provides supports for building XDIME Portlets which stands for xHTML device independent markup extensions, and is a device independent language.

So one can argue that there are other XDIME based frameworks available for designing and developing Mobile enabled Portlets and what value does IBM Mobile Portal accelerator provide? I believe the key benefit is that the Mobile Portal accelerator runs on top of a robust WebSphere Portal middleware platform which provides security (single sign-on), customization, personalization, navigation etc. out of box along with scalability and performance.

In summary, using Mobile Portal Accelerator, you can provide Web Content, services and applications to mobile devices while maintaining the benefits and advantages of a Portal Website; these benefits include:
  • Multi device support (per IBM, it supports 6000 devices)

  • Creation of content using device independent markup to create mobile applications

  • Separation of logic, layout and branding

  • Delivery of new network services, applications and content quickly

In the next part of this blog series, we will go into the discussion of technical architecture of Mobile Accelerator and what key components the framework offers and how they all fit together with WebSphere Portal.

Stay tuned…


Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

Monday, May 24, 2010

Why we love using Rational Team Concert to automate the build, deploy and test of WebSphere applications

Greg Hodgkinson, Methodology Practice Leader


Team Concert continuous integration for WAS, WESB, WPS, Portal and WMB?


So you love what you’ve heard about the benefits of Rational Team Concert for improving the development performance of Java development teams, but you’re wondering if it works just as well for your WebSphere Application Server, WebSphere ESB, WebSphere Process Server, WebSphere Portal Server or WebSphere Message Broker applications?


Well wonder no more – it does!


Being better at delivering better solutions


First some background.


Here at Prolifics we specialize in helping our customers deliver business solutions running on the various WebSphere runtime platforms. In fact we’ve delivered so many that I don’t even think marketing keeps count anymore! And as we have such a focus on software development, we are especially interested in any solution that allow us to do a better job, more efficiently, and greater ease.


This explains why we love Team Concert so much.


• From the point of view of a project manager – the always-up-to-date visibility of exactly what is going on at any point in time, what issues the team is facing, the current progress trend, what has been delivered most recently, what tasks are overdue, what the current status of the build is – all combine to allow a greater level of control over the project. They say control is an illusion, but an informed project manager is more likely to make the right choices for the project.


• From the point of view of the developers – the powerful but easy to use source control with private back-up space on the server from where changes can be shared with others and accepted from others, the ability to easily pause changes and switch over to another piece of work, the feed of information of what the rest of the team is up to, the prioritizable to-do list of work items, and the powerful build automation engine that allows the build/deploy/test process to be automated and provides automated feedback on the quality of code being delivered to source control – these features allow developers to be far more productive and to operate as a team with far greater confidence that they are on the right track.


• From the point of view of testers – the ability to interact directly with the developers using the same collaboration platform that they do, with a tightly integrated round-trip from defect, to code fix, to build, to release – increasing the efficiency of not only reporting and fixing the defects, but getting fixes back out to the testers to be re-tested.


• From the point of view of the business (our customers) – they see an improved predictability in project delivery dates, increased quality in the solution delivered, reduced times to fix defects, improved visibility into the activities of the project team, and insight into what it is that is being delivered – all which mean that project budgets will be signed off with a high certainty of success.


Simply put, the tool has been revolutionary in helping us being better at delivering better solutions for our customers.


Continuous integration is vital


An important factor in our success with Team Concert is its build engine. Continuous builds are well known to be a highly effective way to improve the coordination and efficiency of a team of developers and Team Concert’s build engine does this brilliantly – along with the change sets (source control component) and work items (work item tracking component) that it traces to and from, and the dashboard that exposes its results and outputs to the team and beyond.



The process is simply and yet the effects are powerful.


1. Developers deliver their code changes, along with suitable unit tests that verify the correct operation of their code.


2. The Team Concert build engine will trigger the build either based on a continuous interval or a defined schedule.


3. The build engine fetches the code changes, the unit tests, and the automation script that will drive the build.


4. The build engine sets up a build area containing the code, the tests and the automation script, and then executes the script. Depending on the script used, it can automate a number of steps involved in creating a candidate release of the code, for example:

a. Compile the code and unit tests

b. Deploy the code to an application server (normally a dedicated continuous integration testing server)

c. Run the tests to ensure that the deployed code works correctly.


5. The build engine then publishes a build output record which has immense value to the team. This record contains the deployable unit(s) produced by the build, the logs that were produced as a result of the build activities, the results of running the unit tests, a snapshot of the exact configuration of code, tests and automation script that the build engine used, and the contents of the build both in terms of the work items and code changes that went into it.


6. The team is notified of the results of the build via a number of mechanisms: the build will appear as a notification in each team members IDE, an entry in the project feed on the dashboard, a new build in the builds section of the dashboard, a new entry in the team central view. If there has been a failure, then everyone will know about it, and the team can get straight to work on correcting the issue.


Permanent point of reference for releases



This build record forms a permanent record of the build that is immensely valuable to any future developers or release engineers that need to understand that particular build. They can very quickly determine what went into the build and what was produced by the build.


Neutralization of integration errors


A key step in the automated process steps described earlier is the “Notify team of completed build” step.


This is important for two reasons: Firstly, any further steps required to take place such as smoke tests can now take place, so notification is important.


Secondly, and most significantly, if the build failed it is important that the team is aware so they can take steps to correct the causes of this failure. Having a broken build is a bad situation because it means that the quality of any new changes that are delivered cannot be verified, so it is important that steps are taken immediately to rectify the problem.


Normally the responsibility falls with the developer whose delivery broke the build to correct things, but it is important that the whole team is aware of the situation. It doesn’t take long for developers to learn how important it is for the broken build to be fixed, and we’ve found that this detect-notify-correct process becomes very efficient at neutralizing integration errors that could otherwise require far more effort to correct once they are compounded and confused by further changes.


Zero “wait time” to produce a release


Every build is a candidate release! Or at least every build that succeeds . No more delays having to request a release engineer to create a release of the code, waiting while they gather the correct source and scripts to produce the release, and then manually deploying the release for smoke tests. Essentially every time a successful build has run you have a potential release ready for smoke tests. The “wait time” has gone down to zero.


Prolifics “project-proven” on all WebSphere platforms


To get back to the original question: Continuous integration with Team Concert is all very good and well for Java projects, but what about more advanced applications built on WAS, WESB, WPS, Portal or WMB?


Well you will be glad to know that it is exactly these kinds of projects where we have seen the most benefit out of using Team Concert’s build engines – especially those projects where there is a combination of technologies involved. We have successfully used the Team Concert build engine along with our own automation scripts to realize the benefits discussed above (permanent point of reference for releases, neutralization of integration errors, and zero “wait time” to produce a release) and many further benefits in building applications across all of the WebSphere platforms.



New starter scripts solution available on IBM Global Solutions Directory


Would you like to use your Team Concert build engine to automate the build, test and deployment of WAS, WESB, WPS, WMB or Portal applications? If so then our starter automation scripts are ideal to get you up and running quickly.


Contact us to arrange a no-obligation demonstration where one of our build engineers can show you how the solution can be used to speed up deliver on your target platform.


See the new listing in the IBM Global Solutions Directory for further information and also watch this video!


Greg Hodgkinson is the Methodology Practice Leader at Prolifics. He has worked in software architecture since 1996, initially in the field of component-based development (CBD), then seamlessly on to service-oriented architecture (SOA). His extended area of expertise is the software development process, and he assists Prolifics and IBM customers in adopting agile software development processes and SOA methods. Complementing this is his expertise in software development environment architecture. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods, has co-authored a Redbook on SOA solutions, and regularly writes for DeveloperWorks.

Wednesday, February 24, 2010

Lotusphere 2010 and Mobile Portals

Don Sheppard, Solution Director

One of the most interesting sessions I attended at Lotusphere 2010 was not about a new version with enhanced features, nor about a new product that will revolutionize the industry. It was a simple session on taking existing portals and making the content display better on mobile devices using the IBM Mobile Portal Accelerator.

Viewing web content on phones and PDAs has been around for a number of years, but in the last year it has really caught on. During 2009, we saw a large increase in the amount of smartphones in use. Apple shipped the new iPhone 3GS, Google Android-based phones like the Nexus One and Droid gained traction, and companies added more types of Windows Mobile-based phones.

As the popularity of interacting with the web using a phone continues to grow, more companies will want to make access to existing content easier on mobile devices. Some companies will build custom applications targeted to devices like Androids or iPhones, but others will not have the time or resources to build device-specific applications. For those companies who want to optimize the mobile user experience of an existing Websphere Portal application, the IBM Mobile Portal Accelerator provides them with the tools and a runtime engine that can optimize the display of a portal page for over 7000 devices.

Historically, creating a site accessible to mobile devices meant stripping out all visually appealing elements and presenting a bare-bones, text only version. This was because every device would render the content differently and few supported advanced technologies like Flash or Javascript. Also, the way a user interacts with a website on a desktop machine is very different than how a user interacts with a site on a mobile device. Desktop or laptops screens tend to be wider than they are tall, so most sites use navigation elements on the top and left sides of the screens. This type of navigation doesn’t work well on mobile devices where the screens are narrow. To deal with these issues, companies could create a mobile page and format the page to support the lowest common device, but this sacrifices the robust experience possible on new devices. Today’s mobile devices still have vast differences; for example an Apple iPhone has a 320 x 480 pixel screen, Rim Blackberry has 320 x 240 pixels, and Google’s Nexus One has a whopping 800 x 480 pixel display.

Mobile Portal Accelerator solves the problem of supporting different types of mobile devices by maintaining a database of device specifications where the attributes of over 7000 mobile devices are mapped. By abstracting the page layout, items can be formatted and converted to provide an exceptional web experience on each device.

Mobile Portal Accelerator uses XML Device Independent Mark-up Extensions (XDIME) to describe the content. One set of XDIME is created to map UI elements and Layout Policies are used to determine where content is shown on mobile devices.

Using XDIME reduces the time to deliver content, because one set of markup is created and can support all devices in the database. As new devices are introduced, a subscription service is available to provide updates. This means a developer no longer has to be concerned with updating the application as new devices are introduced.

Mobile Portal Accelerator is currently available for the IBM Websphere Portal 6.1 platform, supports the publishing of Lotus Web Content Management content, and widgets. It also features eclipse-based plugins called the Mobile Portal Toolkit which works with RAD and RSA to develop and test portlets.

Don Sheppard is a Solutions Director at Prolifics and Master Certified IT Architect. Don spent 13 years at IBM and was former CTO of their National Portal Services practice before working for Prolifics.