A belated congratulations to the JSR 286 group, which went into final release in June. You can get the details here. Good job to Stefan Hepper of IBM, the specification lead, who must have had a tough time herding the cats on this one. Right out of the gate it’s good to see JSR 286 getting some attention from the portal vendors.
Of course it’s been in development for quite some time. When JSR 168 was being created a number of enhancements were shifted to JSR 286 to keep from slowing down the original portal spec’s ratification. The most important features of JSR 286 are inter-portlet communication (IPC) and alignment with the ongoing work on Web Services for Remote Portlets 2.0 (WSRP 2.0).
Vendor support has been promised soon as well (or is already here in the case of IBM).
- IBM quickly announced support in for WebSphere Portal 6.1 (as well as for WSRP 2.0). Way to track the standards guys!
- Oracle’s ALUI and Oracle Portal don’t have support yet. I’m told Oracle Portal may get it in 11gR1 release or later
- JBoss (Red Hat ditched its own portal in favor of the JBoss portal after acquiring JBoss) is promising support in Version 2.7, due out in Q3 2008 according to CMS Watch.
- A document from someone at SAP coldly stated that “SAP supports and actively participates in this new standard as EG member. As this specification is in draft version, it is not supported in NW CE.” I checked with my contacts at SAP and was told that JSR 286 is currently in scope for NetWeaver 7.0 Enhancement Pack 2, which is expected around October. I also noticed they did not vote on the standard. I wondered if this was a sign of lack of interest or a passive way to vote “no”, but their analyst relations staff said it was in fact because their committee representative was in the hospital.
My guidance to portal architects though is to consider bypassing JSR 168 or 286 portlets and even WSRP and focus on creating web services for information that they want to expose. Once the data portion is available as a web service, any decent portal product can create a quickie portlet (maybe in JSR 168 or some proprietary format) from the WSDL of the web service so it can be used in a portal. And then you have the option of leveraging that interface through non-portal mechanisms as well.
I should mention JSR 301 here as well. Presentation models have changed since the original JSR 168 specification was created. JavaServer Faces (JSF), the most significant of the presentation models for Java and has spawned many proprietary and open source attempts to transform JSF interfaces into JSR 168 portlets. The JSR 301 specification is only in its early stages, but promises to standardize these bridging mechanisms. No solid word yet on what that’s coming though.
I just finished watching a Flash movie on integration of SAP into SharePoint (my Tivo’s on the fritz so I couldn’t watch Jon Stewart as planned). I thought I’d post my notes here to save you the 20 minutes or so it would take to watch it here, although you’ll miss out on the nice British accent and spiffy Flash graphics. It matches up pretty well with my outline of Integration With SharePoint and Anything, which proposed a similar continuum of 9 integration levels (from most complex to least) as: Programmatic/API level, Database/Repository/Metadata, Execution, Web Services/SOA, Portlets/Web Parts, Single sign-on, Unified search, Screen scraping, and Linking. They reverse the continuum, but hit most of the same notes.
Here are my notes of the presentation, followed by a few comments:
- Their scenario assumes you store your content in SharePoint and then use WebDAV, web services, or a packaged .NET data provider (.NET Data Provider for mySAP Business Suite) to get at it
- You can use the Business Data Catalog (BDC) to search for SAP data from Sharepoint
- A few low-end methods are mentioned, such as linking, using framesets to embed pieces of SAP portal-displayed views inside a SharePoint page, and embedding customized portlets (not sure what kind they mean)
- WSRP: SAP acts as the WSRP producer in this scenario and SharePoint as the consumer. This is apparently a custom bit of work as you need to produce the xml-compliant templates in visual studio.
- Business Data Catalog (BDC): It doesn’t say whether there is a non-manual way to create the BDC metadata for an SAP system. While SAP systems are highly customized, there are often tools that can be run against them to do discovery of customizations and allow click-and-drag access to data objects. It doesn’t seem like that is done here
- Forms: Online forms from MOSS can be submitted to SAP
- You can develop iViews in Visual Studio. There’s a portal add-on, a portal runtime for .NET, and a Java .NET interoperability plug-in that runs in SAP
- They mention additional integration that is needed such as SSO, multiple iViews in a SharePoint page, and migrating iViews into SharePoint
A few comments from me:
WSRP portlets have been a sticky issue for SharePoint and, indeed, when listening to the slickly produced Flash movie, I can clearly detect that the part about using WSRP portlets from SAP in SharePoint was done as an overdub. The vocal quality and volume changes for that section. It could be they just needed to clarify the technical detail later, or they had to be very careful to say what they can do because one bit of wrong wording would expose some limitations with that method. Or maybe last minute decisions were made that required redubbing (like a lack of packaged WSRP portlets).
They don’t mention unified search between an SAP portal and SharePoint site. If anyone out there has gotten that to work well I’d like to hear how you went about it.
In general, this demonstrates that integration with SAP or SharePoint occurs across several dimensions and any organization looking at integration needs to consider all of them. If a vendor is asked about integration and gives a nice detailed answer about one level (such as portlets) you need to ask about all 9 levels.
As an exercise, the integration that Day Software (a content management vendor) announced today with SAP can be analyzed across these levels as well. Day’s press release says:
Day’s extended capabilities provide out-of-the-box portlets, allowing managed content that is dynamically associated with the SAP NetWeaver Portal, to be displayed through iViews. Presentation capabilities are supported through the use of iViews, themes and external facing portals. Integration into portal navigation and TREX search is also available. Day extends the value of managed content through multi-language support, inter-portlet communication, content sharing and personalization. Support for LDAP and Single Sign-On enables seamless integration into the portal framework.
While the devil is in the details, you can at least see they are touching the bases. Once you see the integration dimension pattern, it becomes easier to assess SAP or SharePoint integration.
PC World reported that SAP announced its intention to purchase Business Objects for $6.78bn. That’s a pretty hefty hunk of change for a vendor that is known as non-acquisitive. But SAP has done acquisitions. It just does less of them then than its free-spending rivals and tends to purchase technologies that can help them grow rather than directly trying to purchase growth by buying their way into new spaces and buying customer bases. Still, SAP has done its fair share of acquisitions, including TopTier and Frictionless Commerce.
There has been a noticeable difference in their approach to business intelligence however. They’ve been on a warpath in 2007 to build out capabilities around business performance management (the other BPM – not business process management). They kicked it off in February by acquiring Pilot software. Then in May they acquired Outlooksoft. The Outlooksoft press release made their objectives clear:
Todays announcement marks another milestone in SAPs multi-year plan to holistically address the increasingly sophisticated requirements of the CFO around driving business performance, managing risk, ensuring compliance and spearheading financial transformation in their organizations.
So the acquisition of Business Objects isn’t a surprise in itself. It’s just a surprise that other parts of the Netweaver portfolio that have been screaming for an acquisition have been continually left to their own devices – namely content management and collaboration (which is shoehorned under “knowledge management”).
SAP has had an opportunity to use Netweaver as a sales leader rather than an ERP followon. Even if they do not want to sell Netweaver as a standalone product, emphasizing the quality of its components – possibly by branding them – may help with market expansion.
So far this opportunity has not been taken advantage of, but Business Objects may signal a change. SAP has stated they will continue to sell it as a standalone product. And in my view, fears that it will become overly tilted toward SAP applications are unfounded. TopTier was a best-of-breed independent product that connected to SAP and non-SAP environments. SAP pledged to continue it’s independence and it did. There was an overall decline in building out connectors by all portal vendors as web services became more prevalent, so all portal vendors have cut back on production of these – not just SAP.
So, historically, SAP has a track record of maintaining the “Swiss army knife” ability of the products it purchases to connect to multiple environments. SAP has realized openness is critical in sales cycles when SAP is presented with the problem of how it can integrate with non-SAP pieces. I predict SAP will maintain the openness of Business Objects.