Tip - Provision a Functional Management page for application data

One of the faces/capabilities of the SharePoint platform is that of Web/Enterprise Content Management System (WCM, ECM). When we architect and setup a WCM-enabled SharePoint (publishing) site, there are actually 2 different types of users to take into consideration:

1. The end-users browsing and using the website;
2. The content managers, who have the responsibity for maintaining the content on the website up-to-date

When designing the website, the primary focus is almost naturally on the end-users. Understandable, after all a site which does not attract and keeps the interest of end-users is in fact useless for the company. However, it certainly is also beneficial to give appropriate attention to the usage model for the content manager role. If they can do their content work in a more user-friendly and efficient manner, the site will most likely benefit from this by being more and more often kept up-to-date. Content management is a task difficult enough on the functional level, without the technical / usage model burden of SharePoint content management.

Content in a publishing website comes in various forms. Most known are of course the publishing / web pages, as the entities to which the end-user navigates. But there are more type of content-entities possible:

• downloadable documents (administered in document libraries)
• pictures displayed somewhere in the site (administered in picture libraries)
• data displayed somewhere in the site. Examples are news items, events calendar, links to related information (administered in SharePoint lists)

When the SharePoint is based on one of the publishing site templates, content management of the individual pages is already to a certain amount enabled for the site contributors. An authorized contributor can start the creation of a new page, or the modification of an existing one directly from the siteactions menu. However, if the contributor needs to change one of the other types of content (document, picture, basic list data), there is no such direct usage model. Instead one has to follow the path of Site Actions --> Site Settings --> List and Libraries --> identify and then select the appropriate list ... This is rather cumbersone, and involves a lot of mouseclicks (irritating) + the retrieval and rendering of multiple application pages before arriving at the final destination (time-costly for the user). Another disadvantage is that the content owner must self identify in the listed overview of all the SharePoint lists and libraries in the current site, the particular list/library which holds the content type.

Wouldn't it be nice to apply a comparable usage model as for page-modification to non-page content items ? I thought so, and have realized it within various SharePoint CMS-projects. The basic usage model is:

1. A contributor selects the Site Actions menu
2. The Site Actions menu is extended with a custom action for functional data management

   
3. The functional data management menu entry navigates the browser to a functional data management page. On this page the different relevant content types are enumerated in list form, with direct recognizable identifications.

   
4. Clicking on one of the content type links navigates the browser to a page on which the data items of the related list are displayed. The contributor can here manage the content of this specific type, for instance news messages.

   

This usage pattern improves the user experience for the content management role:

• The usage model for non-page content applies the same pattern as for publishing page content
• The navigation is direct, and orientated at functional level
• Lesser mouseclicks and page retrievals
• Contributor is shielded of from confrontation with the total collection of SharePoint lists and libraries in the site

At SharePoint technical level the following is done to enable this usage pattern:

1. Entry on Site Actions menu: Provision via a feature a custom action, to add an entry to the Site Actions menu, with it's action set to navigate to functional CMS management page.
2. Functional CMS Management page: Provision a web page with on it a Content Editor webpart (CWEP), and add htlm to render a list of the different content types. Each item in the list hyperlinks to the same edit page for editing the contents of the selected list. The listname is propagated via the QueryString.
3. Editable list view: Provision a second web page with on it a ListView webpart. The ListView webpart is used to display the different items in the SharePoint list or library, and to enter new item or edit existent item. This web page is reused to display the contents of the different content lists and libraries. For this it is required to runtime connect the contained ListView to a specific list or library, following the selection the content manager made from the overview. The ListView webpart itself does not exhibit QueryString behaviour. Therefore a hidden technical webpart is added to the page which parses the QueryString to detect the requested list, and next runtime push this setting onto the ListView webpart on same page.

And that's basically it. Your site's content managers will thank you for delivering this CMS functionality. At least, that has been my experience on several occassions/projects...

Apply WCF BizTalk Adapter Pack to service-enable SAP BAPI/RFC's

One way to expose native SAP BAPI and RFC function modules is by generating a web service within SAP NetWeaver. In some cases this is less appropriate. For starters, you need to have a SAP Developer Key to be allowed to use the SAP web service wizard, and also have the required SAP authorizations. In other cases it may not be allowed by IT operations to make any modification to the SAP environment, even if it's limited to the full-automatic generation and activation of the BAPI webservice(s). Another reason from a system architecture viewpoint, is that the single BAPI and/or RFC calls may be of too low granularity. You actually want to perform a 'business transaction', consisting of multiple method invocations which must be treated as a Logical Unit of Work (LUW). SAP has introduced the concept of SAP Enterprise Services for this, and has delivered a first set of them. This is by far not complete yet, and SAP will augment it the coming years.

The by SAP delivered Enterprise Services will of course be limited to standard SAP functionality. In case of custom functionality you'll need to provide your own 'Enterprise Service' behaviour. This can be done in the SAP environment as a custom BAPI/RFC function module, and then exposed as BAPI webservice. However, another option is to apply the .NET WCF LOB Adapter SDK and the related BizTalk Adapter Pack. The LUW behaviour is then implemented within a .NET class. For transactional update behaviour, the .NET class must invoke BAPI_TRANSACTION_COMMIT at the end in case no problems are encountered, and otherwise BAPI_TRANSACTION_ROLLBACK to rollback all the earlier performed updates in the LUW.

Basic Steps:

1. complement your local development environment:
   i) install the WCF LOB Adapter SDK 2.0
   ii) install the BizTalk Adapter Pack 2.0
   iii) install the SAP RFC SDK
   


2. Generate in VS2005/2008 an 'Adapter Service Reference'; select the SAPbinding, configure the connection to the SAP system and connect, and next select the BAPI's and RFC's function modules that you're going to invoke in your business functionality. Important: if you need to implement a transactional update, also include the BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK function modules.
   


3. Design and implement the client context that applies and invokes the SAP adapter binding.
   

The whitepaper Windows Communication Foundation (WCF) LOB Adapter SDK and the BizTalk Adapter Pack gives the reader a good and thorough insight on the vision and functionality of both. And excellent read for the ones interested in approaches to integrate arbitrair .NET clients (e.g. MOSS) with external Lines of Business application (e.g. SAP HR).

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability WCF LOB Adapter

Tip - WCF LOB Adapter SDKs 'Add Adapter Service Reference' not present in VS2008

The WCF Lines of Business Adapter SDK contains development and runtime functionality to service-enable external applications. I downloaded and installed the SDK, but to my unpleasant surprise no change was visuable within the VS 2008 IDE. In particular, the promised 'WCF Adapter Service' project template is missing, as well as the 'Add Adapter Service Reference' menu option. As first repair I downloaded and installed the BizTalk Adapter Pack (which I'm going to need anyhow, since I want to service-enable SAP business functionality). However, still no change in VS2008...

After some fruitless searching on the web (bing-ing and googling...), I posted a question on the related forum. And thankfully with a quick and useful answer. When I installed the WCF LOB Adapter SDK I choose without really considering it the 'Typical' installation option. It appears however that the SDK authors do not consider the installation of the SDK 'Tools' to be part of the typical installation. A bit strange to my opinion for a development SDK, but instead handy for deployment of only the runtime parts of the SDK on an OTAP server. After augmenting the SDK installation I now do have both the 'WCF Adapter Service' project template as the 'Add Adapter Service Reference' menu option available.

High Performance Workplace - Product Selection Matrix

The mission of TopForce is to design and deliver the concept of the High Performance Workplace within enterprises. The specific portal technology or product to realize this in, is a technical mapping. To arm our consultants with material to make an informed selection and decision for which portal product to utilize, we set up a product selection matrix.

In this matrix we position a total of 17 of what we at TopForce think are the most important portal capabilities, and map these against a total of 15 portal products and technologies. There are more than these 15 available in the market, but we intentionally delimit it to deliver an overseeable selection matrix. Within the weighted portal platforms we have the largest commercial ones (SharePoint, SAP NetWeaver, IBM WebSphere), and several open source products (e.g. Alfresco, Jahia, DotNetNuke, Hippo CMS). Also included is our own TopForce High Performance Portal offering.

The Product Selection Matrix is set up for general applicability. It therefore intentionally does not include the specifics of an enterprise situation. In a concrete selection these must of course also be considered in the decision process. You must think here of their current IT environment plus IT roadmap. However, be aware that one of the most influencing factor is often invisible; namely enterprise politics and personal IT preferences of the decision makers.

The Quest for searching thorough advice on best-practices SAP / SharePoint interoperability

What started out as a rather simple inquiry question on the SDN forum SAP NetWeaver .NET Technologies, is now transforming in a more in-breadth discussion on getting best approaches to apply within SAP / SharePoint interoperability. André Fischer, SAP employee, posted a direction to the whitepaper Interoperability between SAP NetWeaver Portal and Microsoft SharePoint Technologies. Although a good overview document of the possible approaches, that is also its shortcoming: it's an overview, but it does not give the reader solid advice on best approaches to apply in specific situations. Not strange, that is not the purpose of this whitepaper. And also, the answer on such questions is for a major part influenced by the particular enterprise situation, thus difficult to generalize. But when involved in such a concrete enterprise situation, you are in need of such guidelines and advice.

So we try to 'challenge' André to come up with more concrete advice. If you're interested, follow the forum-thread to see whether he accepts and responds to this...

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability architecture guidelines roadmap

A reflection on 'Enterprise Portal'

Wikipedia contains the following definition for the concept of an Enterprise portal: An enterprise portal, also known as an enterprise information portal (EIP) or corporate portal, is a framework for integrating information, people and processes across organizational boundaries. It provides a secure unified access point, often in the form of a web-based user interface, and is designed to aggregate and personalize information through application-specific portlets. One hallmark of enterprise portals is the de-centralized content contribution and content management, which keeps the information always updated..

I agree with this definition on the conceptual level. However, I want to supplement it with a fundamental notion on a more architectural level: Enterprise Application Integration. Especially the concept of business process integration is achieved by combining the functionalities of multiple business applications within one single employee workplace. The High Performance Workplace.

Patterns in Enterprise Portals

Industry analysts and portals vendors identify the following set of enterprise portals patterns / types:

1. Content portals
   Aggregates enterprise content from many sources throughout the enterprise. Typically augmented with search functionality to allow employees to find the requested information quick and easily. Authorization applied at content level to protect sensitive information.
2. Transaction portals
   Extend content portals by not only displaying documents and textual information (unstructured data), but also provide the employee with the means to access and operate individual application functionality direct from within the portal. The applications are provisioned via individual portlets in the portal, and provide on-the-fly / realtime business data (structured data), and allow users to interact with the application via the portlet.
3. Collaboration portals
   Support a team in collaborating on a mutual task. This can be a project, an assignment, or the performance of the daily and regular team responsibilities. The collaboration features enable the employee to self-organize the ad-hoc work, and share + work on the same information through a dedicated team workspace.
4. Process portals
   Compared with the individual and non-connected silos in a transaction portal, the process portal provides the employees with an integrated business process that spans multiple back-end systems. The employee is not aware of single applications, but can rather enlist in the total business process.

Enterprise Portals platforms

An enterprise portal is not a shrinked-wrapped product, but requires configuration, customization and provisioning to be of added value for an individual enterprise situation. Custom development is often required to achieve enterprise specific functionalities and integration. Portals vendors position their enterprise portal product more and more as an Application Integration Platform. A.o. SAP uses the phrase "Applistructure" to point out the combination of out-of-the-box enterprise applications and functionalities, together with application infrastructure. Applistructure capabilities which are expected in an enterprise portal platform offering include the following:

• Presentation services
• Content aggregation
• Data management
• Enterprise search support
• Webservices / interoperability support
• Team collaboration support
• Document handling
• Enterprise Content Management
• Web Content Management
• Workflow support and integration
• Business Process Management
• Business Intelligence functions
• Personalization
• Site design and structure
• Branding
• Authentication and Identity Management
• Authorization, roles management
• Operational management support
• Multi-channeling
• Functional management support

Commercial and Open Source

The enterprise portal product space consists currently of numerous parties. Some are the well-known traditional technology-stack vendors, but more and more also (commercial) Open Source platform offerings come up. Here is a list of some of the major current players in this field:

• IBM - WebSphere Portal
• Microsoft - SharePoint
• SAP - NetWeaver / Enterprise Portal
• Oracle - BEA WebLogic
• Sun Microsystems - GlassFish Web Space Server
• Vignette Corporation - Vignette Portal
• Tibco - PortalBuilder
• Liferay - Liferay Enterprise Portal
• Red Hat - JBoss Portal
• Jahia
• Alfresco
• Covisint
• DotNetNuke

Trends and new capabilities

Incorporate Web 2.0 capabilities (Wiki's, blogs, social computing), Mashups, Rich User Experience, Mobile usage, Cloud Services, incorporation of Self Service applications

Related sources

• Introduction to Enterprise Portals - Why they Benefit IT and the Business
• Gartner about (Enterprise) Portal Scenarios
• Gartner - Magic Quadrant for Horizontal Portal Products, 2008
• ZDNet - 12 predictions for Enterprise Web 2.0 in 2008
• ZDNet - 8 predictions for Enterprise Web 2.0 in 2009

Schematic overview of SAP enabling technologies for SSO

I came accross a figure displaying a graphical overview of the diverse paths and approaches for achieving Single Sign-On within SAP. This nicely summarizes at high-level the available approaches as discussed in the SAP/Microsoft Alliance whitepaper on SSO (see posting Studying Single Sign-On approaches for SAP and Microsoft):

Tags: SAP NetWeaver Microsoft SharePoint integration interoperability SSO identity management IDM IAM