IView Web Part restrictions in MOSS 2007

Looks like it’s a big week for EP/MOSS interoperability. Yesterday the SharePoint Team released the WSRP Toolkit for SharePoint 2007 and today the SAP interoperability folks at Microsoft released a new white paper explaining the limitations of the IView Web Part and how to get around those.

I’ve encountered the infinite refresh loop issue described in the introduction of the white paper. The IView Web Part uses an IFrame to display the iView from SAP, but sometimes the web part will go into an infinite loop. This can now be addressed by developing a simple custom web part using an HTML object tag for displaying the iView. Simply follow the guidelines in the white paper.

WSRP Toolkit for SharePoint 2007 released

The SharePoint Team has just announced a new WSRP Toolkit for SharePoint. This is a great step in the right direction for portal interoperability. WSRP is a web services protocol for aggregating content and interactive web applications from remote sources which you can read more about here. In the following, I’ll use the generic term ‘portlet’ for what Microsoft call a ‘web part’ and SAP call an ‘iView.’

Microsoft Office SharePoint Server (MOSS) enterprise edition has all along included two web parts for bringing portlets from other portal technologies into SharePoint, the WSRP Consumer Web Part and the IView Web Part. The first one can be used for consuming any WSRP conformant portlet from any portal technology and the second one is specifically for consuming SAP NetWeaver Enterprise Portal (EP) iViews. So even though not all iViews in EP conform to WSRP standards, you can bring almost anything across from EP to MOSS because we have the IView Web Part. It’s pulling portlets in the other direction that’s been the problem up until now and the only approach has been custom development.

It’s important to emphasise that what’s been released now is a toolkit and not an upgrade to the product, meaning that producing WSRP conformant data in SharePoint still requires development. But this development has just become a whole lot easier using this toolkit. It’s still not as straight forward as it could be, but it’s certainly a step in the right direction and it shows that Microsoft continues to invest in open standards for interoperability.

Understanding SharePoint for what it is

Microsoft markets SharePoint as a platform for connecting people, process and information. That could mean many things. And it certainly does mean different things to different people. Microsoft provide a bit more detail on this page outlining the capabilities of MOSS but that’s not really enough information to really understand the platform.

Lots of issues follow from not properly understanding the platform. I have seen several projects fail because SharePoint was being used for something it was never designed for. Often people get carried away and want to believe that one miracle product can solve all problems. That is obviously not the case.

The key point is that it takes time to fully understand SharePoint. And once you do feel you have a reasonable good understanding, remember that others might not be there yet. If you’re a SharePoint consultant, keep in mind that people you work for often will have misconceptions about the platform and it’s part of your job to lead them to a better understanding.

If you’re feeling slightly lost in terms of understanding SharePoint or want some guidance on how to make other people understand SharePoint, I’d advice you to read the following three landmark blog posts. They’re all fairly brief so it’ll be well worth your time.

• SharePoint is not the Holy Grail by Patrick Tisseghem.
  SharePoint often gets criticised based on the wrong assumptions. If you expect SharePoint to be able to solve all your problems, you will be disappointed. The product was designed for certain purposes and should be measured against those purposes.
• SharePoint = Platform (and Application) by Arpan Shah.
  SharePoint is not an end-to-end solution. It’s a platform upon which you can build solutions. SharePoint has some particular strengths around serving the long tail of specialised needs within an organisation.
• Your (Share)Point of View by Woody Windischman.
  Did you ever hear the old parable about the blind men meeting an elephant? This is a brilliant analogy to the size of SharePoint and the many different perceptions of the product.

Using the SharePoint BDC to access SAP data

I was listening to the SharePoint Pod Show Episode 12 about the SharePoint BDC. It’s a great discussion which gives you an excellent introduction to the BDC, but it also includes some valuable insight into some of the more advanced things you can do and at the end they share common issues that people out there are encountering. Very interesting.

The podcast also references a survey about the proliferation of the BDC. It caught my attention that not many are actually using the BDC for connecting to SAP. I presume, this is first of all because the majority of companies running SAP is typically committed to SAP Enterprise Portal more than MOSS. A second reason is the relative complexity of it which I will elaborate on in this post.

As I indicated in a previous post, even in very SAP-centric organisations the proliferation of SharePoint is inevitable. This is usually driven by people in the business asking IT to provide SharePoint’s collaboration functionality. SharePoint is also a front-end for an increasing number of Microsoft's other server products (Project Server, PerformancePoint Server, Team Foundation Server, etc.), so it tends to emerge one way or another.

If you run SAP as your back-end and you have SharePoint widely deployed, it’s a natural progression to consider bringing SAP data into SharePoint using the BDC. The main driver for this is to increase productivity of casual users by allowing easy access to SAP data in an environment they are comfortable in and thereby minimise their reliance SAP power users.

So, if you do want to use the BDC for bringing SAP data into SharePoint, what are the challenges you’ll be facing? Well, here are a few based on my experiences:

• Developing BDC-friendly web services.
  As mentioned in the podcast above, the BDC requires the web services representing your LOB system to be structured in a certain way. Unfortunately, that certain way is not anywhere close to what the SAP web services look like in a standard SAP environment. They return results through inout parameters rather than out parameters and there’s a separate WSDL for each method whereas the BDC requires all methods for all entities in a LOB system to be accessible from the same URL.
  If you’re coming from a .NET background, it is tempting to address this by developing your own custom .NET web services layer on top of the SAP web services. Although this can be useful in order to create a quick and dirty conceptual proof-of-concept, it’s not something that’s recommended in a production scenario. You obviously end up with poor performance having the data serialised and deserialised twice and you will face serious challenges getting the users authenticated all the way through.
  The right thing to do is developing custom ABAP web services on the SAP side, designed specifically for the BDC. Give the ABAP developer the guidance required to develop web methods that are fit for purpose (Finder, Specific Finder, Id Enumerator, etc.). Also, it’s preferable to have the ABAP developer extract field names from the SAP system saving you from having to do any manual mapping of names in the BDC application definition file.
• Finding the right skill sets.
  As with any solution that spans across multiple technology stacks you will need to find and coordinate people with different skill sets. You will need a good ABAP developer to build the web services on the SAP side and that developer will need to work closely with a SharePoint technical resource that knows the BDC well. And they will have to put aside any religious technology arguments for another day and subscribe to the idea of leveraging the best of both worlds.
• Getting security right.
  When you talk to organisations about bringing SAP data to a broader user base, concern number one is always security. Configuring authorisation hierarchies in SAP is often an expensive exercise and a lot of time and effort has gone into it. You want to leverage that investment. In reality that means you’ll have to get Single Sign-On working, so the users are authenticating through and access levels are managed in SAP.
  There are a couple of ways you can go about that. You can either architect your infrastructure to implement SSO (refer to the white paper Unleash the Power of Single Sign-On with Microsoft and SAP) or you can take advantage of SharePoint’s SSO service (guidelines available in the white paper Interoperability between SAP NetWeaver Portal and Microsoft SharePoint Technologies).
• Focusing on the right use cases.
  SharePoint is a great environment for deploying functionality to casual users of other applications. That includes access to SAP data. But you’re not trying to pull SAP power users away from the SAP GUI. You’re aiming at occasional users of SAP. Users that only sporadically need to look up some information in SAP. It’s great for scenarios where users are currently having to go through SAP power users to acquire the information they need. And it’s typically to support collaboration-oriented activities rather than transaction-oriented activities.