IBM ExperienceOne solutions aim to “Deliver real-time flow of insights and interactions—at scale.” IBM Web Experience Factory is a part of the IBM Customer Experience Suite. With Release 8.5 the product continues to evolve as a framework that can build a solid application that integrates with the many layers in the Digital Suite. The ultimate goal is to deliver solutions that empower the customer across the digital experience.
A lot of what we discuss around Web Experience Factory is about the technical aspects and that is very important. There are times new (or old) developers hit road blocks in the learning curve and need technical guidance. IBM and the WEF community have some great information available and at Davalen we have the Master series along with our consulting experiences. Once you begin to “master” building applications, I believe that Web Experience Factory’s strength is not just the first time you develop a digital experience. It’s the second, third, and later times that you come back to update the application and how it maintains all of the integration points with other applications.
For those of you that travel, you reach a time where you know exactly what you need to pack for four days away from home and generally pack it the same way. When I unpack at the hotel there is confidence that I have everything I need. For this article I would like to summarize some essentials that I believe are important to “pack” for your solution. The emphasis will be on Web Experience Factory with the mindset no application is an island to itself. My challenge to you is to give feedback some of your experiences in these areas and some essentials that you may have in your WEF suitcase. Together we can help Web Experience Factory as it continues to mature into a world-class framework.
Essential: Coding Standards
Even though a large part of Web Experience Factory is builder based, we still need to establish coding standards. The table below is a list of some standards we have used in the past. In Agile fashion, our standards can and have changed as we worked through their implementation. Some examples are:
- Project Names and Project Folder Structure
- Model Names and Folder Structure
- Builder Names / Setting
- Java Objects
The standards established above should be published. You could use a wiki or a document, but the developers and leads need to know the standards.
Essential: Code Reviews
Standards are of no use unless they are followed and that leads to code reviews. Depending on the size of the team, the review can be very formal or just having a peer review. Code should be reviewed as it is being released to the Development environment so that it will be corrected before moving up to higher environments.
Essential: Application Documentation
Documentation has many different levels and layers. This article is about documentation located in the WEF project
One common way to document models is using Comment Builders to organize builders. We have established a basic outline of comments for our service provider and consumer models. A shell model is used for each one in our common folder. This allows the developer to just copy and paste the comments into a new builder. You also can create your own builder based on the Comment builder where you formatted the comment pane based on the type of Comment.
Experience Factory has a “Model Report” that can be run from the Eclipse designer. The information is good, but we want to pull out key information that can help us analysis or debug our application. For example we want to know all of the “Post-Action Behavior” selections in a model since one incorrect selection can affect the whole page. Peter Wilkerson (Davalen) has done some great work in this area. He has created documentation of the model directly from the generated XML.
Any decision made in the project that is not a “normal” setting should be documented. For example if it is decided in a Service Consumer builder to check the “Use Request-Scoped Result Variables”, this is something that needs documented for future developers. One way to do this is to put a short comment in the builder itself and then use the technique in the previous paragraph to pull out the comments into a summary document.
One other area of documentation to mention is any integration points with other applications. That would include products of the Digital Experience Suite such as IBM Connections and IBM Web Content Management. Those “integration points” will be important for the next essential.
Testing is also one of the essential items in the success or failure of your digital experience. An application with many integration points becomes a challenge for the developer to test as changes and updates are made. Those often become “points of truth” when the application has errors. You may be told “Portal is down” when it turns out that the “point of truth” is that the Connections server is down or the Web Services have been changed.
One tool that we use is Selenium for automating our application. Using the tool we were able to automate the successful “happy path” and over time add alternate paths. This allows the developer to quickly regression test the latest changes.
For applications that use SOAP services we use SoapUI to setup the valid requests to the services. As we setup the application we can test the services and then later if something is down then we can first test the service and then work up if it is working.
Overall for testing, we try to maintain the loose coupling of layers so that each layer can have its own set of tests.
This has been a brief look at some essentials for your application. They each have much more depth. It’s the customer and the solution that are the focus. The essentials help us to “deliver exceptional customer experiences.”
About the author: David Wade is a Portal / Web Experience Factory Consultant with expertise as a developer, team lead, and architect. Before joining Davalen, David was an employee of IBM as a Senior Specialist and as the Portlet Factory Lead for GBS and recently an independent consultant. He has worked on major Portal projects across the United States. David’s Portal / Portlet Factory background began as a consultant at a manufacturing company in SC. After IBM purchased Portlet Factory from Bowstreet in 2005, he developed and implemented a complete production line system using Portlet Factory on WebSphere Portal connecting with the iSeries. Prior to his Portal experience David spent 20+ years as an iSeries Applications consultant delivering solutions in the manufacturing, education, and media industries.
This article is from our monthly resource e-Newsletter. Did you miss it in your inbox? Visit our eNewsletter archives for past editions or if you want to receive our monthly newsletter automatically, simply write to Ruth O’Keefe and request to be added to our E-Newsletter list. You can also view the Master Series Archives.