Overview
IOMS is a set of internal and external (to SharePoint, more on that later) services, some web parts, application pages, and a site collection layout. All of this is presented in to SharePoint with a solution file.IOMS directly surfaces reports in a couple of different ways. First you have the Report Repository view, that is, essentially, just a representation of your BOE folder hierarchy presented in a web part. Navigate through the folders and click on the report you want.
The other way is to use a viewer web part (part of IOMS) and, using an ID property for the specific report, directly present the report to the user.
All of this makes it very easy to directly surface reports, however we run in to some problems that, as SharePoint users, we don't expect.
First and foremost, it must be stressed that the IOMS product is just a "window" in to the BOE system. You are using SharePoint to look in to your BOE deployment. Because of this, you don't get the nifty features that we are used to in SharePoint. The Report Repository is NOT a SharePoint library. You can't add metadata to the library, you can't filter the results, you can't group the items, and you can't create document workspaces for the reports. In fact NONE of the whiz-bang features that we have come to use and love in SharePoint are available. What see is only what you get in BOE.
IOMS does give you a "discussion" feature for the reports, BUT, again, it is not a SharePoint discussion, so you don't get all of the features that we are used to in a discussion list. Users of SharePoint using IOMS out of the box will be immediately frustrated, especially if they are used to the new SharePoint 2010 features of metadata filtering, workflows, and external data columns.
Technical Stuff
IOMS is actually pretty interesting under the hood. It is as if the IOMS development team looked at the development story for MOSS 2007 and said "Let's do one of each!" There are web parts, internal services, external services, site layouts, content types, feature sets, and all sorts of other goodies.
Installing IOMS you will find that the majority of the code goes to the SAP Business Objects folder in the Program Files directory. At its heart, IOMS is a Java based application, and all of those java jars need to go somewhere. In this folder are the external services and other things that make IOMS work. SharePoint sees them via virtual directories in IIS in the _layouts folder. These are all treated as IIS applications, sharing the same Application Pool as the SharePoint Web Application.
The problem with this is that each application in IIS requires its very own web.config file. So you constantly need to go back to this folder to adjust the settings. It wouldn't be so bad if there was only one or two applications. However, SAP has a separate application for each type of report they offer. So, there are applications for the Web Intelligence reports, the Crystal Reports reports, the flash dashboards, etc. Each one has its own unique configuration, and you need to make changes in each web.config file to ensure that each type of report will load properly.
One other annoyance that I found was that the IOMS installer will deploy a bunch of stuff in to SharePoint directly, but the thing that it needs to work correctly is deployed via solution... AND they don't deploy the solution for you. You have to manually deploy the solution. That kind of sucks... You see in your site templates the SAP site, but you get errors when you try to deploy it, because the assemblies haven't been deployed yet. Same thing with several of the features and web parts. It is a big pain.
Claims Authentication Mode
Now to the big kicker... Claims Authentication Mode is new to SharePoint 2010. It gives the most flexibility for authentication, while still providing the ability to use Windows Authentication. Most SharePoint administrators and architects recommend that you create your Web Applications as Claims Based.
This does some things internally to SharePoint. When a Web Application is set to Claims Mode, all internal authentication happens via claims. Your windows tickets are converted in to claims tokens. This works all well and good for any SharePoint service, as they are all claims aware. However if you have a third party service that is deployed to SharePoint as an internal service, i.e. in the _vti_bin without being recognized as an application in IIS, it must be claims aware, or authentication will fail.
There are two very important WCF services that IOMS deploys to the _vti_bin as internal SharePoint services.
Remember when I said that IOMS is simply a "window" to your SAP deployment? I am not kidding. The report viewers do not actually exist on the SharePoint server. They exist on the SAP server. IOMS has code that opens a connection to the SAP server's web interface and presents the viewer in kind of a goofy Iframe setup. The service that starts all of this nonsense is this internal SharePoint service. Guess what? It is NOT claims aware. Therefore, no mater what you do, if your Web Application is set to Claims Authentication Mode, authentication will fail to this service. In order to use IOMS, your Web Application MUST be set to Classic Authentication mode.
This is a big gotcha, and in order to understand what is going on, you need to brush up on what is actually hapening under SharePoint's hood. First read about Planning Authentication, then read all about Claims Authentication Mode and what it means to you.
My Deployment
I like all of the SharePoint features... So does my client. So, I am doing my best to create a happy medium for surfacing their reports, AND using SharePoint features.
For the initial deployment, we will be creating a list that will have an entry for each report that exists in BOE. This will be a SharePoint list all of the neat things that SharePoint has can be used. For the time being, when a new SAP report is published, an administrator will have to go in and create a new list item for that report. In the future, when a new report is published, I will have some sort of job on the SAP side that will kick off a workflow in SharePoint to create the list item automatically, then inform the administrator for approval, and to fill in any blanks left by the SAP side.
Of course all of this is just marking time until my client purchases the Duet Suite developed by Microsoft and SAP in tandem. Duet creates connections in SharePoint's Business Content Services enabling us to create external content types and columns for our lists. Once that happens we can develop custom lists that will directly surface reports and metadata from SAP automatically.
