Connecting to SAP from Microsoft Office Infopath

Connecting to SAP From Microsoft Office InfoPath

Technical White Paper

Published: April 2004

Authors:Lindsey Allen,Dennis Wang

Contributing Authors: Tudor Toma, Yancey Smith, Foad Vafaei, Karen Olson (BuzzBee)

April 2004

Table of Contents

Introduction

The Challenge of Unstructured Data

Business Process Automation

The Power of InfoPath 2003

Executive Summary

Building a Web Service via Visual Studio .NET

Configuration

Programming the SAP .NET Connector Client

Generate the Proxy

Generate the Vendor Search Proxy

Configuring the Connection to SAP

Create the Front-end Web Service for Proxy

SAP Toolbox

Steps to Call RFC

Data Type Mapping

Consume the Data Within an InfoPath Form

Create the InfoPath Form

Conclusion

Appendix I Debugging SAP Client

Appendix II Overview of .NET Connector Classes

Introduction

The Challenge of Unstructured Data

Businesses create, capture, and manage information in myriad forms: as structured data in operational systems, as documents that are published and shared, and in countless e-mail messages.In recent decades, methods have been established for storing and managing structured information, for example, numerical data in databases or financial records and statistics.

However, a significant portion of the information created in today’s business environment has remained unstructured and, as a result, cannot be processed in any meaningful way. This unstructured data can come in the form of Word processing documents, Web pages, email, presentations, customer contact notes, etc. According to Gartner Group, “more than 75 percent of enterprise data is unstructured and document-related, rather than being neatly sorted numbers in a database.”[1] To make matters worse, organizations are facing the daunting challenge of heterogeneous platforms, multiple systems, and front-end applications that don’t integrate well with back-end systems. Companies are finding that an inability to integrate critical business processes is limiting their ability to respond well to ever changing business conditions. These challenges have led businesses to search for a means of organizing and leveraging their core resource – their business intelligence.

Business Process Automation

At the heart of every enterprise are numerous document-driven business processes that determine how information is to be collected, reported, published, shared, and stored. Document-based processes, including financial reporting, proposal management, contract management, recruiting and other business activities, influence the ways organizations collaborate on work; how they communicate with partners, customers, and shareholders; and how they store or archive information for reuse and retrieval.Facing dramatic changes in the business world, organizations are finding it essential but difficult to manage these business processes end to end. Businesses need to make faster, more informed decisions. They need the ability to better manage the flow of information to connect applications, people, partners, and data.

Microsoft provides a complete platform for end-to-end processes, solving problems common to many organizations today. Chief among today’s business challenges is ensuring easy access to information. Microsoft’s technologies enable companies to easily integrate desktop applications with line-of-business and back-office applications and enterprise data silos, allowing people to work more effectively. Automating business processes with the Microsoft Office System empowers information workers by connecting the desktop environment to enterprise data. It provides the tools that enable sophisticated analysis and reporting. Ultimately, it can improvethe day to day processes that make workers more productive.

The Power of InfoPath 2003

In particular, an overwhelming number of business processes rely on the use of forms to capture data and initiate the required actions. Through InfoPath 2003, the Microsoft Office System provides an intuitive forms-based interface that enables organizations to create rich applications based on their own processes. InfoPath 2003 makes it easy for developers to create and deploy rich, forms-based solutions for enterprise processes. It provides developers with a facile interface for constructing dynamic, interactive forms with built-in business validations and business rules for accurate and efficient collection of information. InfoPath allows rapid solution creation Web services, eXtensible Markup Language (XML) data, or by allowing creation from scratch. It works with customer-defined schemas which eliminates the need for any schema mapping. Built-in script editor, rich object model and programmable task panes allow developers to build more advanced solutions.

InfoPath also addresses a core problem in data collection and integration needs in the enterprise via XML. While XML has great potential to enable application integration, its use typically requires a development background so it is primarily employed in back-office and data center applications. InfoPath brings XML functionality to the desktop by allowing users to gather and manage business data in XML without requiring those users to know the language themselves.

Executive Summary

InfoPath 2003 is a powerful front-end to business processes. By connecting InfoPath to backend line of business applications, organizations can increase efficiency by streamlining and automating repetitive processes. This helps shorten time-to-market by eliminating manual steps in information handling, by improving the quality of the data and minimizing errors. This reduces response times and delivery of goods and services. Companies can improve quality of service by deploying processes around best practices that ensure quality and consistency in products and customer service. Integrating the desktop applications with line-of-business and back-office applications and enterprise data silos allows people to work more effectively. Empowering Information workers to define their own processes reduces the need for IT departments to be involved with lines of business on a daily basis.

This paper demonstrates Microsoft’s ability to connect the desktop to a line of business system on the back end. It showcases how InfoPath 2003 can be easily connected to SAP to empower information workers to easily create and gather data.

This paper is intended for a technical audience. The first section of the paper describes how to configure and use the .NET connector to call remote functions in SAP. The second section of the paper provides guidelines for creating a front-end Web service (SAP WSDL or Web Service Description Language) interface for the .NET connector proxy through a sample solution (retrieve vendor information from SAP). This front-end Web service will retrieve the SAP dataset via the .NET Connector, and expose this data to InfoPath. Finally, the third sectiondemonstrates how to build a simple InfoPath form to consume this data.

Building a Web Service via Visual Studio .NET

One of the compelling business reasons to connect InfoPath 2003 to SAP is the ability to easily retrieve and reuse vendor information from an SAP system. To do this, you will need to create a Web service through a configuration via Visual Studio .NET. The new Visual Studio Tools for the Microsoft Office System technology brings the power and productivity of Visual Studio .NET and the .NET Framework to business solutions. Using managed code with Office 2003 allows developers to create applications with a more robust security model, restricting code that can execute only on a fully trusted corporate server. This .NET environment also simplifies deployment, saving time and money by not requiring a manual installation of code on each desktop.

Configuration

The following sections will walk you through step-by-step guidelines for building a Web Service via Visual Studio .NET.

First, you must have Visual Studio .NET installed on the development machine. You can download the .NET connector from the SAPWebsite. You will also need a Java Runtime and Visual Studio .NET for your development environment. To deploy your solution, you will need LIBRF32.dll (SAP release 6.20 or higher), SAP.NET.Connector.dll and the Microsoft .NET Framework installed on your production environment. You will need the Java virtual machine for development purposes. It is used only at design time to get metadata from the SAP system (DDIC) to generate the proxy. It is not needed during run time. The design elements for Visual Studio will be installed at %Program Files\Visual Studio.net\Common\IDE. The rest of the connector components will be installed to %Program Files\SAP\SAP .net connector\. Please refer to the release notes for more installation related details.

Programming the SAP .NET Connector Client

To build a Web Service via Visual Studio .NET, you will also need the SAP .NET Connector Client. The SAP client allows your .NET code to execute SAP functions that are remote-enabled (RFC). In the SAP client solution, the SAP system is the server and the .NET application is the client that interacts with the RFC. When you generate an SAP client application, a WSDL file is added to your Visual Studio .NET project. This WSDL file in coordination with a custom tool in Visual Studio creates several C# classes needed to communicate with the SAP system via either RFC or SOAP. There is one class for the proxy itself, one for each export parameter and two for each Table parameter in your RFC.

The SAP RFC is called as a method of the proxy object. There can be one or more RFCs per proxy. For example you could have a proxy with all customer-related RFCs in one library. The parameters for each RFC can be customized within the Visual Studio designer so that optional parameters can be removed, parameters can be renamed and default values provided. You can also customize SAP structures by renaming or removing fields. Visual Studio developers can work with the SAP proxies in their choice of programming language. The proxies themselves are generated in C#. For projectswritten in other languages you have to add a new project of type SAP Connector Class to the Visual Studio solution.

Generate the Proxy

Next, you will need to generate the RFC proxy. The RFC proxy is a small piece of C# code that represents everything you need to call remote functions in SAP (please see the illustration below).

Figure 1. SAP .Net Connector Proxy

The connector proxy includes C# classes for each unique SAP Tables (SAPTable) parameter and each unique SAP Structure (SAPStructure) parameters in the RFC you select. All the RFC call information is available to you at design time. The proxy supports both SOAP and traditional RFC in the same proxy. You can create the proxy from one of the following sources (also show in the wizard screen shot):

1. SAP system directly
2. SAP interface repository
3. An existing WSDL file

Figure 2. SAP .Net Connector Wizard

Generate the Vendor Search Proxy

Next, you will need to generate the vendor search proxy. To show you an example of this, we have created a vendor search in a mocked sample. Z_Get_Invoice_By_Vname is the RFC we used in the sample to return vendor names matching the search criteria. We use the SAP .NET Connector to create the C# proxy SAPWSSample. ZINV02Table isthe class created based on the SAPTable and ZINV02is the class created based onSAPStructure.

By default, the wizard will use the name of the project that the proxy belongs to as the proxy name space and it is SAPWSSample in our case. You can change the proxy namespace on the SAPWSDL file “Custom tool Namespace” property. The .net connector code generator will automatically update the proxy definition.

The following is the sample proxy:

//------

using System;

using System.Text;

using System.Collections;

using System.Runtime.InteropServices;

using System.Xml.Serialization;

using System.Web.Services;

using System.Web.Services.Description;

using System.Web.Services.Protocols;

using SAP.Connector;

namespace SAPWSSample

{

// Client SAP proxy class

[WebServiceBinding(Name="", Namespace="urn:sap-com:document:sap:rfc:functions")]

publicclass SAPProxy1 : SAPClient

{

// Constructors

public SAPProxy1(){}

public SAPProxy1(string ConnectionString) :base(ConnectionString){}

// Generated method used to call the remote function module Z_GET_INVOICE_BY_VNAME

// Throws:

[RfcMethod(AbapName = "Z_GET_INVOICE_BY_VNAME")]

[SoapDocumentMethodAttribute("

RequestNamespace = "urn:sap-com:document:sap:rfc:functions",

RequestElementName = "Z_GET_INVOICE_BY_VNAME",

ResponseNamespace = "urn:sap-com:document:sap:rfc:functions",

ResponseElementName = "Z_GET_INVOICE_BY_VNAME.Response")]

publicvoid Z_Get_Invoice_By_Vname ([RfcParameter(AbapName = "NAME",

RfcType=RFCTYPE.RFCTYPE_CHAR,

Optional = false,

Direction = RFCINOUT.IN,

Length = 35, Length2 = 70)]

[XmlElement("NAME", IsNullable=false)]

string Name,

[RfcParameter(AbapName = "RETURN_CODE",

RfcType=RFCTYPE.RFCTYPE_CHAR,

Optional = true,

Direction = RFCINOUT.OUT,

Length = 50, Length2 = 100)]

[XmlElement("RETURN_CODE", IsNullable=false)]

outstring Return_Code,

[RfcParameter(AbapName = "INV_DATA",

RfcType=RFCTYPE.RFCTYPE_ITAB,

Optional = false, Direction = RFCINOUT.INOUT)]

[XmlArray("INV_DATA", IsNullable=false)]

[XmlArrayItem("ZINV02", IsNullable=false)]

ref ZINV02Table Inv_Data)

{

object[]results = null;

results = this.SAPInvoke("Z_Get_Invoice_By_Vname",newobject[] {

Name,Inv_Data });

Return_Code = (string) results[0];

Inv_Data = (ZINV02Table) results[1];

return;

}

} // rfm client proxy

} // Namespace

After following the above steps, you should now be ready to create the wrapper Web service to front-end the vendor search proxy (SAPProxy1). This Web service will expose a Web method to call the RFC function. In order for the consumer of the Web service to retrieve data from SAP, we need to address SAP access security in our Web service. SAP .NET Connector supports all SAP authentication options.

Configuring the Connection to SAP

To connect to SAP you need several pieces of information:

•Client number

•Application server (or group)

•System number

•User name & password

The connection to SAP is managed within the proxy’s connection object. You do not have to determine the status of the connection; the connector manages this automatically.Before an RFC can be executed, the connection must first be opened. After the RFC has finished executing the connection should be closed. For applications that have many concurrent users, the connector provides a connection pool object. It is possible to get the connection from the pool instead of creating one for each client. In this way connections are reused and performance is improved.

The .NET Connector makes it easy to perform SAP authentication in your application with the Destination and SAPLogonDestination classes and in ASP .NET applications with the SAP Login Form. The SAP connection components (destination and SAP Logon Destination) take the place of a connection string such as the one below:

“ASHOST=iwdf9087.wdf.sap-ag.de. SYSNR=0 CLIENT=800 USER=scooby PASSWD=****”

We recommend you use the SAP logon classes rather than manually creating a connection string with the logon information. The SAP logon classes support getting logon information at runtime from a configuration file (Web.config), SAPGUI or as another alternative, programmatically, for example from Microsoft Active Directory.

The following is the authentication code from the sample solutions:

// create destination class

SAP.Connector.Destination dest = new SAP.Connector.Destination();

SAPProxy1 P = new SAPProxy1();

try

{

// provide dest information here

dest.AppServerHost = "mysystemname";

dest.Client = 122; // put your there

dest.SystemNumber = 0;

dest.Username ="????";

dest.Password = "****";

// passing this destination to SAPconnectionPool to reuse the connection

P.Connection = SAP.Connector.SAPConnectionPool.GetConnection(dest.ConnectionString.ToString());

}

catch (SAP.Connector.RfcAbapException ex)

{

…

}

finally

{

P= null;

}

Create the Front-end Web Service for Proxy

The following section illustrates how to create the front-end Web Service, or SAP WSDL interface, for the .NET connector proxy through a sample solution. (The sample solution we choose is a common business scenario of retrieving vendor information from SAP.) This front-end Web service will retrieve the SAP dataset via the .NET Connector, and expose this data to InfoPath. Before we start to create the Web service, let’s first review the SAP tools.

SAP Toolbox

SAP Toolbox provides convenient VS.NET integration during development time. Below is a screen shot of the Toolbox.

Figure 4. SAP Proxy Toolbox

Before beginning to build the front-end Web service for the proxy, first familiarize yourself with this Toolbox. Following is a list of functionality in the SAP Proxy Toolbox:

• Destinationstores connection information to the SAP system.
• SAPIDocSender sends IDOC files to the SAP system.
• SAPIDocReceiver receives IDOCS from SAP system using TRFC Server model.
• SAPLogonDestination like Destination but also works with SAPLogon to retrieve destination list from SAPGUI.
• SAP Table Wizard adds SAP Table parameters from the proxy to your application.
• Connection code is the template code for logging on and executing a method in SAP.

Steps to Call RFC

The following diagram shows the steps you need to go through to call an RFC in VS.NET so that you know what to do in order to create the front-end Web service for your SAP .NET connector proxy.

Figure 5. Steps calling RFC

In our sample, we created one Web method (SAPRFCWSMethod1) to front end the RFC Z_Get_Invoice_By_Vname. The following is the Web service sample code.

using System;

using System.Collections;

using System.ComponentModel;

using System.Data;

using System.Diagnostics;