We were proposing a single window access to existing system landscape of a company by leveraging on existing capabilities of SharePoint Portal and newly onboarded SAP Enterprise Portal 7.0 on ECC 6.0.
In the context of application strategy we defined in IT strategy that Share Point Portal and SAP Enterprise Portal will coexist in the same landscape through seamless integration giving user comfort and feel of navigation to different backend system to carry out role specific tasks.
Share Point portal will be entry point to Single window system and provide navigation to back end SAP System. User Management in context of users who can be external users as well internal employees of company uses Active directory where all user registration will be stored and validated and henceforth will be integrated to SharePoint portal and Enterprise Portal .
A single sign on solution will be implemented by taking into consideration of SAP systems with SAP Enterprise Portal as well SSO between SharePoint and SAP Enterprise portal. Reporting and its publication will be addressed by leveraging on SAP Enterprise Portal integration with BW and other corresponding system (HR) .The reports will be made available at SAP Enterprise Portal which will be fetched to SharePoint Portal Using SAP WEB Parts inbuilt into SharePoint portal. This solution also in future can be used for content management scenario.
User Management &Single Sign On Solution :Assumption:
Active directory being the integrated, distributed directory service included with Microsoft Windows server 200X and Microsoft Windows 200X Server, provides a central user repository used to centrally maintain user data, thus avoiding the redundant, error-prone maintenance of user information in several systems.
Solution:
We had recommended usage of SAP Central User Administration for maintaining SAP user records in one central system and distributing relevant information to all other SAP systems .This provide a single point of administration of all sap user data and entire sap system landscape at one system.In context of COMPANY users will be maintained i.e. profiles will be maintained at Active directory and that in turn will be synchronized to SAP CUA through using SAP LDAP Connectors . For e.g. addressing functionality of SAP HR as depicted below using RFC and LDAP SAP HR attributes can be directly mapped to Active directory service so in context of application strategy a user who have been registered with SAP HR can be directly profiled in Active directory, or if user existing in SAP CUA can be synchronized to Active directory service.
SAP HR attributes Mapping with Active Directory
Active Directory synchronization with SAP CUA on WAS
Using SAP- LDAP Connector connecting to Active directory
In the context of SAP Enterprise Portal Company Users are stored in active directory and active directory groups can be assigned to portal roles while Portal specific information is stored in portal database like group à role assignment, user àr ole assignment .Multiple domains will be supported if trust relationship can be established between different domains in active directory forest as well if an attribute for e.g. Account name can be used as Portal user id being unique in landscape. We would recommend LDAP access of portal to directory should be secured by ssl.
The bigger picture of the User Management solution will be as depicted below
SAP enterprise portal will be SSO with all other corresponding and relevant SAP system using digital Certificates being preferred over user id and password mapping. In this context identified systems from SAP Perspective will be SAP BW, SAP ERP, SAP XI as this are systems available from Company IT strategy and of relevance for first phase roll out in context of portal addressing future flexibility with regards to SAP IS-U, SAP IS-OIL, and SAP CRM .SSO solution with respect to SAP as a bigger picture in context portal will be.
In the context of coexistence of SAP Enterprise Portal and SharePoint Portal it is necessary to single sign on between two portals to have seamless integration.This type of single sign on leverages on Microsoft single sign on capability using windows share point services and SAP.net connectors which are readily available only needed to be configured. In this context it is essential to mention SharePoint Sap Web Part which will be acting as window for communicating with SAP enterprise portal keeping interoperability feature open, Using SAP logon tickets for SharePoint PortalThe single sign-on functionality enables scenarios where multiple Web Parts access different enterprise applications, which each use a different type of authentication. Each Web Part can automatically sign on to its enterprise application without prompting the user to provide credentials each time. There are endless uses of single sign-on functionality within an enterprise environment. For example, let's consider two different scenarios-a human resources intranet site and a business intelligence site, as follows:
a>A standard human resources (HR) portal site or page might include several Web Parts that display employee information from a back-end employee management system. This employee data is stored in a dedicated HR database system, frequently based on SAP. These HR databases do not support Microsoft Windows IDs, might not run on Windows-based operating systems and, in fact, might include proprietary logon protocols. The Web Parts on the portal site should retrieve the individual employee data without prompting for a separate logon. In this example, the individual employee does not have a separate logon to the HR system, but uses a group account that provides generic read access to the database. In other words, the employee does not know the user name and password required to log on to the system he or she is accessing.
b>An executive might use a portal site to provide a dynamic, aggregated view of relevant business information. This data is stored in two places: SAP CRM stores the customer relationship information, and SAP FICO and Payroll tracks accounts and payments. To see an integrated view, the portal must log on to and access both back-end systems. Prompting the user for additional passwords is an unacceptable user experience. In this example, the executive does not need to know the user names and the passwords required for logon to the back-end systems. In addition, multiple Web Parts are used to ensure this integration. By default, each Web Part separately authenticates the user to the appropriate back-end system.
When individual enterprise definition is used, on the first access to the Web Part that integrates with the enterprise application, if a user's credentials have not been stored in the single sign-on database, the user is redirected to the logon form that prompts the user for appropriate credentials for the enterprise application. The number, the order, and the names of the fields in the logon form are configured by the administrator within the application definition; the logon form is generated automatically based on these configuration settings. The developer needs to write the code within the Web Part to check whether the credentials exist in the database, and to redirect the user to the logon form if necessary. The user-supplied credentials are then stored in the credentials store and mapped to the Windows account that is this user's account for SharePoint Portal Server. Then, the user is redirected back to the original Web Part. The code in the Web Part then submits the credentials from the credentials store to the application in the way that is relevant to this application, and retrieves the necessary information that is then presented to the user within the Web Part.
Concrete Steps are as follows
1. A user accesses the Web Part that integrates with the enterprise application for the first time. The Web Part code checks whether the user credentials for the required application are stored in the single sign-on database.
2. If there are no credentials stored for this user for the required application, the user's browser is redirected to the logon form for this application.
3. The user supplies credentials for the application.
4. The supplied credentials are mapped to the user's Windows account and stored in the single sign-on database.
5 User is redirected to the original Web Part.
6. The Web Part retrieves the credentials from the single sign-on database.
7. The Web Part submits the credentials to the enterprise application and retrieves the necessary information.
8. The Web Part is displayed to the user.
The Overall solution in context of User Management and SSO with respect SharePoint Portal and SAP Enterprise Portal will be:
The figure below illustrates that a user logs in the COMPANY Share Point portal SAP Web part validates user credential with respect to MSAD and after validation user is exposed to SAP functionality required through SAP Enterprise Portal which in turn been integrated to MSAD as CUA for centralized user administration with respect to SAP as well single sign on to respective backend system so the business functionality get exposed properly in SAP iviews which will be displayed through web Part on Share Point.
Document Management solution using interoperability between SharePoint Portal and SAP Enterprise portal
In the context of document management system used in Company we would recommend to use SAP Enterprise Portals Knowledge Management platform along with SharePoint portal as decided in IT strategy. The use of WEBDAV protocol is inevitable in this context as it ensures that users in both the portal can navigate to document repository irrespective of enterprise or share point portal.SAP Enterprise Portal infrastructure provides WEBDAV SERVER and WEBDAV Client. SharePoint portal needs to use WEBDAV Connector. The Connector will make it possible to access document libraries in Windows SharePoint Services from within KM. KM user will be able to add, modify and search documents and manipulate their properties from within KM iViews even if they are located in a Windows SharePoint Services site. In the context of a web based content management system that can be integrated with SAP Enterprise Portal application using application integrator component where users in sap Enterprise can be mapped to web-based document management system and users can have Content management system in sap enterprise portal in same window in the form of a generic iview which can be shown in SharePoint portal using SAP WEB Part.The present way of storing documents in hard drives in the form of folders can be specifically mapped to Content management Repositories of SAP Enterprise Portal using WEBDAV where users has to be directed to store documents in specific folders on their desktop and that folder will be baseline for WEB Folder and that can be mapped directly to CM repository. This needs reorganization of documents in specific folders of application basically under a root folder which will be mapped to Portals KM repository and displayed in form of KM Navigation iview and can be viewed from SharePoint portal using SAP WEB Part.
Portals Interoperability using Portal Launch Capability through URLS
In the context of Company Energy IT strategy it is evident that SAP Enterprise Portal will be used for all Backend integration with SAP systems ,Keeping this in view we would recommend you to use URL integration to the core functionality to be viewed from portal either ways .This implies we can optimize cost and implementation time frame. This necessitates that some of development that needed to take place while creating SAP WEB Part which will be a window representation of SAP Enterprise Portal as well keeping Project Cockpit in consideration of COMPANY can be designed on the basis of URL links for easy navigation from one core functionality to other which may be spread across to other enterprise application or web enabled application without navigating away to different windows. Web Parts are the basic building block of the user interface in a SharePoint solution. Windows Share Point Services comes with a number of Web Parts, and many more are available in the online Web Part gallery. Compared to the SAP Enterprise Portal,Web Parts are counterpart to iViews. Web Part Pages contain one or more Web Parts. The layout of Web Parts on the corresponding page is defined by Web Part zones. This concept is similar to SAP's portal pages that contain one or more iViews in a defined layout. As a rule, a Web Part page contains several Web Parts as you can see on the screenshot related to a Project Cockpit (Using Microsoft share point services) below.
The procedure required to implement this scenario comprises adjustments of SharePointPages and creation of default URL iViews and other corresponding objects like sites,Worksites or roles in SAP EP.Web-based URL iViews in the SAP Enterprise Portal provide a simple way to create iViews that retrieve content directly from a Web page or Web-based application. Technically, a URL iView is a collection of meta attributes. The URL targeting the informationSource is one of them. The wizard for creation of an URL iView provides a built-in Browser enabling you to navigate within a Web site in order to retrieve the URL of the Source Web page. SAP iView Web Part Toolkit for SharePoint Products and Technologies, which enables SharePoint administrators to display SAP Portal iViews within Microsoft Windows SharePoint Services/SharePoint Portal Server. It was designed for scenarios with SAP Enterprise Portal and SharePoint running in parallel, and the need to expose selected iViews also in SharePoint.The toolkit contains a custom Web Part, called the iView Web Part that provides a window onto a running iView on a SAP Portal page. In addition it contains two executables which extract metadata from an SAP portal page and generate a Web Part page .Hope this blog illustrated the approach from my past experience towards interoperability and can be used while defining coexistence of portals in same landscape independent of technology.
