In this series, I’m showing how Portals don’t have to be heavyweight. In Part 1, I wrote about how to make the infrastructure lighter by using cloud or IBM’s Pure System. In Part 2, I introduced the concept of using IBM’s Web Content Manager system to build very simple portlets.
A typical web page or application consists of several sections:
In WCM, we can create an authoring template that contains four HTML fields, one for each of the sections described above. The authoring template also has a workflow associated with it so we can control the publishing of our code.
Read the rest of this post »
In part 1 of this series, How to Implement Lighter Weight Portals, I wrote about the infrastructure and installation aspects of Portals. To make the tasks of managing and installing portals, I recommended cloud solutions and for IBM, their PureApplication system both in the cloud and on-premise.
In Part 2, I turn my attention to applications and how to make task of developing portal applications more lightweight.
The goal of a portal is to combine applications and content at the glass for a user. By this definition alone, we should always think of how to make lightweight portlets. If you have a larger application to build, break it down into core components that can be built into separate portlets, rather than one large portlet.
Even if you can get to smaller, bite-sized applications or portlets, you are still faced with the underlying framework imposing additional layers on your efforts. We’ll focus on Java-based portals to make the discussion simple and I’ll use IBM WebSphere Portal as an example. Say we want to simply display a feed from Reuters as shown in our first picture here.
To create a portlet for use in IBM WebSphere Portal, a developer is going to use IBM Rational Application Developer (already a heavy-weight tool), create a new project using a wizard, fill in some details about the portlet, like name, Java version, etc. and then hit go. RAD will do a nice job of building the portlet shell with all the right components set up. These components include xml files, TLD files, libraries or references, file folders and start JSP files. Already, we have a lot of code to manage.
Once I put in my custom code, I then have to build the project, create a .war file, and then deploy it to WebSphere Portal. After its deployed, I can create a portal page, and my new portlet and I’m all set. In most IT shops, build and deploy to production can take weeks or months just because IT has to control the changes to production very tightly.
If I’m a business guy who just wants a very simple portlet, this makes portal look heavyweight to me, but its likely the process than the technology.
So how to fix this?
Sometimes I’m amazed with what some of our developers do. I’ve seen so many examples of code just thrown together. I’ve seen that code produce infinite loops, slow down load time by a factor of 10, and take down servers. So when I see an example of someone thinking through how to efficiently create code, I’m amazed. Anyway, Parshva Vora, a Sitecore developer here at Perficient, just blogged on how you can use mapping to create agile code and more efficiently get at the latest content. I’ll use some of his own words
Let’s talk about motivation first. I was dealing with a problem involving aggregate object where information needed to be retrieved seamlessly from various and diverse data sources including search index without spreading data access code into my models and views. Does’t it sound like classic case of data mapping problem? In fact, Sitecore 7 content search APIs similar approach where indexed content is filled into specified .Net object(typically into SearchResultItem or its derivative). And mapping is directed through IndexField, IgnoreIndexField and few other attributes. Now it begs an obvious question, why would I use Glass.Mapper? Consider following scenario:
Say you are dealing with an item with large number of fields and not all of them are being indexed(indexing comes at a cost so you like to index select item fields, for instance fields that appear in search results). And while processing search results, some of those non-indexed fields need to be referenced. One way is to make sure that the ID field gets indexed and then using ID, you retrieve related item from database. However the process could be non-transparent and messy, particularly if field is complex or nested field type and there are several fields. So instead of you pulling information from database with Sitecore APIs, Glass.Mapper can do it for you, with the help of mapping attributes. Consider following model for an article where its number, title and summary are retrieved from index and content and images are retrieved from database.
Parshva goes on to get into how it works and to show the benefits of the mapping approach. It’s worth reading the whole article if you have similar needs.
CIO.com has an interesting article about why patient portals just aren’t popular. I think the author, Brian Eastwood, gets some things right but also misses some key reasons or challenges. Here’s what he got right.
Now I don’t disagree with what Brian says. I think he makes a number of great points. But I also take issue with one point he makes:
So what will get patients to use a portal? It’s not as hard as providers may think. The functionality that patients told Software Advice that they want – scheduling appointments, paying bills, viewing lab tests, refilling prescriptions and emailing staff – should sound familiar (on the face of it, at least) to anyone who regularly uses ecommerce applications.
Here’s the reality. Patient portals are hard. They are harder than many ecommerce or consumer sites that sport similar functionality. Frankly, they aren’t that much harder from a technical perspective but there are a number of issues getting in the way. Let me name a few of them.
I want to make one final comment which Brian gets right in his article. I think that with lots of room for improvement comes a lot of opportunity for healthcare providers to truly engage their patients. A lot of these providers are looking to the future and asking what it will take to do true patient engagement and to add in features like sensor uploads, better reporting, proactive personalization that helps you understand what’s in your medical record etc. So while it’s an uphill slog, the future is bright.
One of the complaints we often hear about horizontal portal systems is they are complicated and feel “heavy”. What makes a system feel heavy and how can we lighten the load?
In a typical portal application we have to integrate multiple applications, content and document management systems, security, search, personalization, page management, etc, etc. is it any wonder why a portal would feel heavy when you try to bolt together all these systems? Some vendors have taken the approach that they will build all of these components into their horizontal portal, which makes them seem heavier out of the box. Other vendors go lighter out of the box, but then put the burden on others to integrate the missing parts.
Given that portals are naturally heavy, what can we do to lighten them up or make them appear lighter?
First, let’s talk about requirements. Do you really need all these systems integrated to accomplish your goals? If not, maybe simpler web pages built off simpler content management systems maybe all you need. For example, if your site is going to be content only or mostly content, then you probably don’t need a full blown horizontal portal.
But let’s assume a horizontal portal makes sense. Then you’ll likely need the portal software, an application server, a database server, an http server, a security system like LDAP, and maybe a few other servers just to get started. From an install and infrastructure point of view, that is a lot of heavy lifting to install all those servers and get them to work together.
To make this infrastructure lighter or appear lighter, we can turn to cloud vendors, or in the case of IBM their PureApp system. Let’s look at cloud vendors first.
If you’ve kicked the cloud tires yet, you know it is fairly easy to get individual servers up and running. You can request a database instance, an http server, security, and an application server and have it running in minutes. In the portal world you may still have to install the portal server separately, but some vendors are able to have that provisioned too. In most case you still have configuration steps to take to get all of those servers to work together. Still the cloud makes the portal infrastructure feel lighter because you didn’t have as much work to do to get it running.
What if you can’t go cloud and have to stay on-premises? IBM has tackled that problem with their PureApplication System. With PureApp, IBM has defined system patterns and has created the tooling necessary to implement the patterns automatically. For a portal environment, an IBM pattern looks like this: two portal servers clustered, an http server, a db2 server, and a Websphere Deployment Manager. That’s a lot of servers and configuration and feels heavy.
In PureApp, with this defined pattern, the system can install and configure a complete WebSphere Portal production environment is less than an hour. Five servers, fully configured and operational in less than hour. Now that feels much more lightweight. My colleague Kate Tuttle just posted an article on our Healthcare Blog about how Blue Shield of California used PureApp in their portal implementation project.
In the next part of this post, I’ll talk about how to make portlet development lighter weight. Here is a link to part 2: How to Implement Lighter Weight Portals, Part 2: Portlets
Last week Forrester published their first Wave on Digital Experience Platforms. I was at the IBM Digital Experience Conference and it sounded like IBM was expecting good news from Forrester in this wave. In fact, Stephen Powers from Forrester was the Keynote speaker at the conference and one of the principal authors of the Wave.
Much to every one’s surprise, the Wave came out with nobody listed as a Leader. Adobe, hybris (SAP), IBM and Sitecore came out as the Strong Performers followed by many others in the Contender category. Nobody was listed as a Risky Bet.
So what gives? Really no Leaders? Dom Nicastro wrote a story last week about this development: Forrester Wave: No Leaders in Digital Experience Delivery.
Forrester considers a Digital Experience Platform a full end-to-end delivery platform and most vendors fell short in the completeness of their offerings. Each vendor seemed to shine in one or more areas, but nobody stood out as having all the components needed to be a Digital Experience Leader.
For me, part of the issue stems from how Forrester defined the market. hybris from SAP is strong in Commerce, while Adobe and Sitecore are more known for their Web Content and Marketing capabilities. So the companies included in the wave are really all over the map, in my opinion.
Is it fair to compare commerce systems with WCM systems? Yes and no. If you need commerce in your digital experience, then you want to know who has commerce capabilities. If commerce isn’t important, then no and the analysis gets skewed.
There is a lot of interesting information in the Forrester report, so I encourage you to read it yourself.
I don’t know how I missed it but Harish Bhavinachikar has a nice post on what you can do with modern UI tools in WebSphere Portal. It’s on our Spark Blog but addresses something that keeps coming up again and again. Frankly, the front-end tools have changed considerably in the last couple years. Modern UI tools / frameworks like AngularJS, Bootstrap, JQuery, and a host of others make it easier to manage the UI and to further enforce separation of the front-end from the back-end. While a horizontal portal like IBM’s WebSphere Portal does some of that, it wont’ take you all that way. But as Harish explains, all is not lost. You can still leverage those frameworks and best practices within the portal. I’ll let you read the entire post but here’s his list of Myths. Note how he is also telling you some best practices here.
Myth – Websphere portal is not compatible with latest front end frameworks like bootstrap, foundation, jQuery Mobile, etc.
Myth – Websphere portal is not compatible with jQuery and associated plugins.
Myth – To make a change in the css file, this should be done in the portal theme, deployed to QA, tested and then served to production.
Best Practices a Front End Developer needs to follow while working with portal theme.
I’ve blogged about this before with Candace’s Part 1 and Part 2. She just published Part 3 in the series. Here she focuses on what to do once you’ve extracted and transformed the content. In other words, getting that web content into the target system. In this case it’s Sitecore, a popular .NET based WCM. I think it’s great Candace took the time to walk through a step by step approach to this. Go to her post for the full set of steps and details.
Once data is extracted and transformed, the clean data is sitting in database tables ready to be uploaded into Sitecore. Sitecore has an Item Web API available for uploading data, but it is limited to basic retrieval, creation, and update operations. How was I going to tie related records together? How could I perform basic if/else operations that were necessary? It was obvious almost immediately that the Item Web API would not be adequate.
Because I had so much system specific processing to do, I decided to write my own upload process, using the Sitecore API. If this were an ongoing process, it would have been necessary to build a more automated, flexible way to upload this data, but because it was a once and done operation, and time was short, the solution outlined below was sufficient. I wrote a rather ugly web page that allowed me to click through the upload process quite quickly:
You can also see some of what Candace describes at a much higher level on Youtube
Brendan Callum, a director and whiz extraordinaire in our Salesforce practice, has a video out about what they did with Google Search and Salesforce. The video doesn’t go into a lot of detail but I find it extremely interesting that an appliance (older trend) searches the cloud (ongoing trend) in a secure fashion. Of course, why do you need detail when someone developed a connector for it and all you have to do it buy, install, and go.
Hilton announced on their web site that they plan to change the game when it comes to the guest experience at their hotels. While the press release doesn’t state the investment, the Wall Street Journal quotes it at $550 million. But what’s really cool is that the smart phone will become:
At first glance you may wonder why it costs $550M but if you think about it, Hilton had to do quite a bit to make this work. First they had to enable a map. That probably comes from a back end system or two or three or four……… Of course, you have to then do the integration and put a nice wrapper on it because I guarantee that it doesn’t look good to start. When you add in new amenities and want to build an infrastructure that’s more ecommerce like, then you make even more work for yourself. Using NFC or some other standard also ensures a change in every single hotel room lock. That will probably drive the majority of the cost.
But think about what they get out of this investment. First, they get the cache of being first with a key enabling technology. Second, if they architected this right, they setup their application to do everything. If you can get a special amenity ordered up then how hard should it be to order room service? How about adding in concierge requests for tickets to that special event or restaurant? Of course there’s the chance to treat all the elite guests in a special way. They walk through the door and notify them you opened up a set of rooms they can choose for an upgrade. Tell them they just earned faster internet or that they should stop by the mini-store for a treat. The skies the limit as far as what you can do now that the Hilton App became a must use application.
I’m excited about the possibilities here.