As a MOSS consultant, I face many situations where Sharepoint is not an island and needs to communicate or to integrate data coming from different sources, different applications (Line of Business Applications) like SAP and others.
Also as a .Net consultant I use to keep my mind structured by thinking in term of patterns, and there are many of them.
I recently talk to a confirmed MOSS consultant about OBA (Office Business Applications), and it quickly appeared that for him OBA was just using VSTO (Visual Studio Tools for Office), which is a tool I appreciate anyway; but Oba is also about MOSS and the client side is often the cherry on the cake.
The following picture illustrates the main OBA patterns, but there are also sub patterns
I will quickly describe the main Oba patterns; for more details you can read this book.
Pattern 1 : Office Applications as a Reach Channel
Goal: we want to make sure people can easily use the Line of Business Applications (LOB) through the Office System (Rich Client or Web Client).
Sub pattern 1 : direct integration
In this sub pattern, we will call the Line of business application directly, typically via Web services; however we can do this from Rich Client (Office 2003 or Office 2007) by writing .Net add ins with Visual Studio Tools for Office. This is professional development, no VBA anymore and the add-in can be updated thanks to the click once technology (improved in Visual Studio 2008).
We can also apply this pattern by calling web services from Sharepoint (like from a web part), but the main issue we will face is that the data won’t be indexed and users won’t be able to retrieve it in the Sharepoint search.
Another issue will be that if the interface with the Line of business application changes, we need to update every proxy (high coupling).
Sub pattern 2. Mediated Integration
Instead of invoking the LOB directly, we will register it into a mediator and we will invoke the mediator from a rich client or from a web client (low coupling).
The typical mediator is the Business Data Catalog (BDC) in MOSS Enterprise; the BDC allows MOSS to interact with Web Services and relational databases (and not just SQl server).
Using the BDC is quite simple, you just have to define the abstractions of your LOB (entities, likes Customer and Orders,…) and the links between the abstractions (like a Customer can have several Orders); you can use tools like the BDC Editor or BDC Meta Man to generate such abstractions in the form of a xml file; you import the xml file in the MOSS Shared Service provider and voilà, you can display your objects in Out Of the Box web parts, in Custom Sharepoint lists or from your custom code (custom web part,…). This is quite easy and well documented.
Another benefit of this pattern is the the LOB entities can be indexed and thus retrieved through the Sharepoint search textboxes of MOSS.
Pattern 2. Document Generation
This pattern is one of the most popular.
The idea is that the data coming from the LOB can be presented as “Documents” like Microsoft Office documents or others.This is possible thanks to new file formats like Open XML or Open Document used mainly in Open Office.
The Lob can 1°generate this documents and 2° Move this documents to MOSS/WSS document libraries.
Generating OpenXML document is very easy, you can use the Package and PackagePart classes of .Net 3.0 ; or much easier the new OpenXML sdk (version 2.0 is still in CTP at the moment). You don’t have to install Office on the server to achieve this pattern (anyway, this was not supported and was very instable).
This was also doable with Office 2003 file formats, but tricky.
If we use Excel Services (provided with MOSS Enterprise), we can generate Spreadsheets (with or without diagrams) and display them in Web Parts like the Excel Web Access web part.
Pattern 3. Document Integration
Sub pattern 1. Embedded LOB Template pattern
Here we insert LOB data in the document and we display the data in specific fields of the document
Sub pattern 2. LOB recognizer pattern
On the client, the application might present context-sensitive information, such as the details of a customer whose name is recognized in a Word document. when a user change any data, then the LOB will be updated appropriately.
Pattern 4. Composite User Interfaces
We define different components in the user interface as illustrated in the picture above where we define our own menu (Custom Ribbon) with VSTO, a custom Task Pane (which is actually a .Net Form, which can also host a WPF control if necessary) ; this custom Task Pane communicates directly (“direct integration pattern”) or indirectly (“mediated integration”) with the LOB to fetch data or to update the LOB.
We can also use this pattern on web user interfaces (see below) when we have several parts (web parts in Sharepoint) communicating together.
Pattern 5.Collaborative Site patterns
The idea is to create a web site to allow a team to work temporally on business objects; for instance when sales department has a new important lead, then a new collaborative web site can be created around this lead, just to figure out out approach the lead; and later on, when everything is clear, we can delete the web site.
Another example is a list of incidents or issues; anytime an issue is created, a new temporally web site can be generated for a team.
Pattern 6. Complementary document workflow
2 sub patterns :
LOB Initiated Document Workflow :
here the LOB will generate a document (“Generate Document pattern”), will place it into a Sharepoint list which will trigger a workflow
In the Cooperating Document Workflow, the LOB will communicate with a MOSS workflow along the way.
Pattern 7. Application generated tasks
I’ve noticed that many MOSS (and non MOSS) consultants often underestimate the power of the concept of tasks as a great way to have a communication channel between a LOB and users.
Sharepoint can be a mediator between the LOB and the user: the LOB can generate tasks in a Sharepoint task list and the user will be automatically notified.