How to integrate other application systems in Sharepoint Server?

Integration of other application systems in Sharepoint Server is actually a complicated issue. You need to consider multiple issues and make the best choice among various options. In this blog, We will systematically describe the integration of SharePoint Server in this aspect, hoping to help you. The Sharepoint Server mentioned in this blog is generic and does not target a specific SharePoint Portal Server 2003 or Office Sharepoint Server 2007.

A friend may ask, How can I integrate the application system? Isn't this what BizTalk Server should do? Yes, EAI (Enterprise Application Integration) is the strength of BizTalk Server. But first, BizTalk Server is better at integrating applications and systems at the application layer. That is to say, most of the ways that BizTalk Server deals with systems are through the APIs of these systems, in many cases, apart from the integration of various systems at the application layer, we also hope to integrate the various applications on the interface, that is, the integration of the presentation layer, the integration of the presentation layer allows you to access and operate multiple application systems on a unified interface and view information in each system. For the integration of the presentation layer, we also need a Web-based platform to do this, which is the strength of SharePoint Server.

Secondly, in many cases, we may not need "heavy weapons" such as BizTalk Server.ArticleLater we will see that only in some complex scenarios, more specifically, customers already have a lot of applications, moreover, only when applications are interconnected, integrated, and integrated can BizTalk Server be used.

Generally, we divide Sharepoint Server Application Integration into the following four methods (the following picture is taken from PPT, so I am very sorry ):

First, Integration Based on Web interfaces

Simply put, you can directly take the web interface of other systems and put it on the page of the Sharepoint Server so that users can access other systems on the SharePoint interface.

This method is the simplest of several integration methods, but it does not mean that it is not practical. Sometimes, Integration Based on Web interfaces may be the best and the most easy-to-use method. There is a prerequisite for using this method, that is, the application to be integrated must have a Web display, otherwise it will be impossible to talk about it. Fortunately, it is now a popular web era, almost all enterprise application systems are presented to customers through web.

Two ready-made Web parts are provided in SharePoint Portal Server 2003 to help us complete Web interface-based integration. The first is the Web Part Of The webpage viewer, which provides a URL that can directly embed the specified page into the SharePoint page in IFRAME mode. The other is the Web part of the web page interceptor, which allows us to specify a part of a web page, and then it automatically intercepts this part and displays it in the SharePoint page, in addition, we can also specify an update cycle. This Web Part checks whether the specified webpage changes over a period of time, and then updates part of the webpage block to be displayed.

Of course, in addition to using the Web part provided by Sharepoint, we can also integrate the web interface in our own way. As long as the basic principle of your method is to get the web interface of another application system to SharePoint, it should belong to this first method.

One of the major challenges you may encounter when using web interface-based integration is single sign-on (SSO), because the web application to be integrated may need to be accessed after login, users obviously do not need to log on again when they want to view the information of another application system in Sharepoint. Therefore, we need to help users automatically complete the logon process.

Type 2: Data source-based integration

For some reason, for example, the system to be integrated has no Web display at all, or SSO is not easy to integrate, and users only need to be able to see the data in that system in Sharepoint, no interactive operations are required (for example, the customer only needs to view the sales data report of the previous month or the customer information table), and we can directly access the database of the system to be integrated, the second method may be a good idea.

Data source-based integration means to directly connect to the database of the system to be integrated, and then use some Web parts to directly display the data of one or more tables. SharePoint provides a ready-to-use Web part, allowing us to connect to any database using ODBC, and then display the data on the SharePoint page. Of course, it is not difficult to create a custom web part to display database data.

An important benefit of this method is that you do not need to consider how the application system is implemented, how it is done, and what interfaces are, as long as you can access its database, you can do it.

An important prerequisite for data source-based integration is that you know where the system database to be integrated is, how to access it, and understand its database structure (data dictionary). That is to say, you need to clearly know which database and which table of which field data should be displayed, which is the data that the customer wants to see.

Third: point-to-point Integration

Point-to-Point integration means that developers can develop custom web parts.CodeTo complete a task in a Web part. This method may be a point-to-point method because it may need to develop a corresponding Web part for every application system or even every function in the application system.

Point-to-Point integration can bring maximum flexibility and functionality, because as long as other application systems have corresponding interfaces, we can complete any function in the Web part: obtain data from other application systems and interact with other application systems.

But this method also has its own premise. First, the application system to be integrated must have corresponding interfaces. If a third-party access is not considered and no API application is designed, there is no way (this type of application system is not uncommon !). Second, if there are APIs, Web Part developers also need to understand these APIs, know how to call them, and which one they need to call. Many application systems are very complicated, it provides a huge and complex API. If you are not familiar with the interfaces of these application systems, the learning cost is not small.

A typical example of point-to-point integration is to access the sap iview Web part toolkit of the SAP system. In addition, it is very valuable to integrate sap into SharePoint: www.microsoft-sap.com/interop.aspx.

Fourth: Application Integration

Finally, in the most complex scenario, we need to use an EAI server like BizTalk Server. If we need to integrate multiple systems, for example, to operate multiple systems in a Web part to complete a task according to a specific process, this integration method should be the most appropriate.

In this way, we need a dedicated Application Integration and Integration Server to deal with various application systems and complete the compilation and creation of business processes on it, then, the integration function is completed by calling the interface of the Application Integration and Integration Server in the Web part.

OK. Now, I have finished introducing the four most common integration methods. Finally, I want to let you know a new one provided in Office Sharepoint Server 2007, the component used for Application Integration: business data catalog.

The above picture (also taken from a PPT, so I am sorry again that the picture is large) shows the overall architecture and role of BDC. BDC provides an intermediate layer in which we can define the metadata of the Data. Then, BDC extracts the corresponding data from the background application system based on metadata, for use by Sharepoint Server.

In BDC, We can first define the application, which basically corresponds to the application system. Then, we can define multiple entity (entity, for example, "customer" and "employee"). Based on entity, we can define its attributes, methods, and actions. After the metadata is defined, BDC can obtain the Entity Data from the backend application system in two ways based on metadata: one is to use ADO. net to access the database directly. One is to access the Web service interface of the backend application system.

After BDC extracts the defined data from the backend application system, some Web parts in Sharepoint Server 2007 can directly display the data and filter and query the data. In addition, the search engine of SharePoint Server 2007 can use BDC data as the content source for retrieval. In this way, Sharepoint Server 2007 virtually realizes the data search function of the business system. Of course, BDC also provides complete APIs that allow us to access the data extracted from BDC in our own applications or Web parts, or write the updated data back to the backend application system.

The emergence of BDC greatly extends the capability of SharePoint Server to integrate with third-party application systems. BDC greatly simplifies data access, operations, and search for backend business systems. For more information about BDC, see the related content in the Sharepoint Server 2007 SDK.