SAP Biller Direct displays account and invoice information via the Internet and provides electronic payment options and various self-services for end users. It accomplishes this by connecting a Java-based user interface (UI) with an SAP Accounts Receivable (AR) system and displaying business data via the Internet. SAP divided the application between Java and ABAP components, which makes the implementation tricky because consultants need to be familiar with both mySAP ERP Financials and SAP NetWeaver 2004 or SAP NetWeaver 2004s technology.

This is the first part in a series of articles in which I’ll describe aspects of SAP Financial Supply Chain Management (FSCM) components, including Biller Direct, Dispute Management, Collections Management, and Credit Management. I’ll describe the architecture of Biller Direct in detail and then focus on the options for setting up user management. Based on experiences from several projects, user management is often the most challenging issue, whether you’ve implemented R/3 or mySAP ERP. This article applies to both systems and is intended for business administrators.

Biller Direct Components and Architecture

While SAP implements most applications with ABAP only, Biller Direct consists of an ABAP component responsible for the application logic and a Java component that you use for the presentation layer. SAP implemented the Java component with JavaServer Pages (JSPs), which means that end customers only require an Internet browser to view data. SAP created this Java component in accordance with the Model View Controller 2 (MVC2) approach, a generic design model that separates the UI from the business process logic and the data.

You can use JSPs to create HTML pages dynamically. As with Java Servlets, you can use JSP for creating the presentation layer of a Web application, so you generally use it for the simple creation of the HTML and XML output of the Internet server. However, whereas Java servlets are application programs written, implemented, and compiled in Java, JSPs are Java commands embedded in HTML documents. At runtime, the Java 2 Platform, Enterprise Edition (J2EE) runtime environment of the Web application server capabilities of SAP NetWeaver 2004s (usage type AS Java) generates a Java servlet from the JSP files, which is executed automatically in the Web browser like any other servlet.

Users can adapt JSPs to meet their needs, for example, to copy the branding of an existing Internet page. The MVC2 approach features the JSP completely decoupled from both the logic on which it is based and the data storage. The user can change JSPs without affecting the logic and the data storage. Biller Direct’s Java component doesn’t have any persistence at all — the SAP back end stores all data exclusively, which affects the user management options I’ll discuss later. MVC2 also ensures that the JSPs contain virtually no Java coding and Web designers can therefore change it without the help of Java developers. Alternatively, you can use the SAP- delivered JSP standard design and change the cascading style sheets to adapt Biller Direct to your own corporate layout.

Biller Direct architecture (Figure 1) enables simple integration in an existing Web or portal infrastructure. You need a servlet engine to execute servlets and JSPs on the Web server. This is a virtual Java machine — a Java interpreter that can execute the Java byte code generated, and, as a result, the Java program on a computer — that can execute specific object methods designated as servlets. A servlet engine is also a component of the J2EE-compatible Web application server capabilities in the system that you need for running Biller Direct.

Figure 1

Biller Direct architecture

The Biller Direct Java application (which runs on the Java servlet engine) and the SAP back end communicate with each other via a Remote Function Call (RFC) using SAP Java Connector (JCo). JCo provides the Java developer with a class library to integrate ABAP components and therefore enables communication between Java and ABAP components. The business logic remains in the SAP Business Application Programming Interfaces (BAPIs) — methods for calling up business objects, such as invoices, in the SAP system. JCo supports bi-directional connections between the Java and ABAP worlds, meaning that a Java client can call up a BAPI in the SAP back-end system and also an ABAP program on the Java server. It provides a high performance Java Native Interface (JNI)-based RFC middleware and supports synchronous, transactional, and queued RFC connections.

The system processes every read access to the SAP back end that doesn’t lead to data changes (e.g., users displays their account data) using connection pooling. The Web application server capabilities in SAP NetWeaver 2004s manage the existing RFC connections to the SAP system. With connection pooling, the system stores RFC connections in a pool of existing RFC connections and uses them again for the next access. It does not immediately disconnect the RFC connection to the application server when it is not needed, such as if a user logs off. This procedure has the following advantages:

• It provides maximum performance because you no longer need to constantly open and close connections
• It places minimal burden on the SAP back end
• You can set up the maximum number of connections on the Web server, thereby having complete control over the maximum load on the back end as a result of Internet inquiries

In contrast, the system executes every write access that leads to database changes in the SAP system (e.g., a user pays an invoice) via an RFC connection under the user logged on, for audit security reasons. This named connection creates a separate RFC connection for each Biller Direct end user. This connection only exists for the time of the individual user action (for example, partial payment of a bill), and the system then disconnects it. This variant ensures that the logged-on user carries out all authorization checks and the system stores all change documents under the actual user. The system assigns all user-specific system parameters the values of the logged-on user.

Compared to pooled connections, named connections consume more resources (such as network connections and memory) because several users cannot share a named connection. The constant recreation of back-end connections and logging on to the SAP back-end system make the named connection slower than pooled connections, and increase the load on the SAP system. Using both access methods for Biller Direct represents a reasonable compromise between performance and security requirements. Most accesses are read accesses, and therefore only require pooled connections. You only need named connections for the rarer write accesses. I’ll show you how to set up named and pooled connections with a new tool in the next section.

Connections and User Types in XCM

You need to set up the use of named and pooled connections, respectively, within Extended Configuration Management (XCM), a Web-based configuration tool designed specifically for Biller Direct (Figure 2). By using XCM, you can set technical and application-specific settings. You can also create your own application and adjust one of the pre-delivered SAP configurations to your needs. Depending on the configuration you use, the Java application behaves differently during runtime. A configuration consists of the configuration name, the base configuration (the SAP configuration on which the customer bases his configuration), and configuration parameters with associated values. If you want to use pooled connections, you need to enter No under the attribute used_named_connections in XCM.

Figure 2

XCM screen

I have already started to discuss the various types of users that you have to implement in the context of Biller Direct. There are three user types:

• Web users: These are the actual end users who log on via their Internet browser and process the data from there — for example, your customers who would like to view their invoices. You shouldn’t assign separate roles and authorization profiles to this type of user because it causes major administrative efforts. You don’t want to manage several thousand Web users with their own roles or profiles. You can create these Web users either within your SAP back-end system or outside. I’ll discuss these two options later in the article.
• Reference users: These are the collective users in the SAP back-end system that you need to set up to assign them to the individual Web users so you can avoid maintaining individual authorizations and user profiles. These reference users carry their own authorization objects and roles, and the system assigns them to the Web users via transaction SU01, provided that you have decided to maintain Web users within your SAP back-end system (Figure 3). Within SU01, you assign this user type as a reference user by selecting the Roles tab. I’m creating reference users with different profiles or roles to differentiate fundamentally different Web user groups (e.g., one reference user who can view invoices but can’t pay invoices). The administrator can group together Web users with the same authorization by assigning a corresponding reference user for each group. All Web users in this group refer with their master data to this reference user without carrying their own authorizations. SAP delivers standard authorization profiles from which you can choose. Run transaction PFCG using the input help and search for FSCM.

Figure 3

Assignment of reference users

• Pool users: I discussed pooled and named connections above. To enable the use of pooled connections, you need to create an anonymous service user with its own authorization profile both in the SAP back-end system as well as within the Java application. This profile must include all of the authorizations that are necessary for the back-end processes; otherwise a Web user couldn’t access all data. Within the SAP back-end system, you create the pool user within transaction SU01 (within the user group technical user). Within the Java application, you need to use XCM to create a pool user (Figure 4). You need to make sure that the names of these Web users are identical. If you need Biller Direct to support multiple languages, you need to set up multiple pool users with different language settings (e.g., an English or German pool user). Within XCM, you can do this by maintaining extra pool connections.

Figure 4

Pool user in XCM

The system must first authenticate every Web user (i.e., customer) who calls up Biller Direct from an Internet browser. You have two options — either you maintain these Web users within or outside of your SAP back-end system. I recommend maintenance within the back-end system if you’re sure that you won’t have to set up many Web users (several hundred or so). Maintaining several thousand or even a hundred thousand Web users within your SAP back-end system puts a strain on both your administrator and system performance. You can control the relationship between the Java application (front end) and the accounting system (back end) using the parameters of the component user management of XCM. SAP delivers the following preconfigured scenarios:

• FI_UserManagement
• CRM_UserManagement
• UME_UserManagement

The first two options imply user maintenance within the SAP system. They differ only regarding the location where the SAP system creates Web users, whether it’s R/3, mySAP ERP Central Component (ECC), or SAP CRM.

Provided that you decided to manage the Web users within your R/3 back-end system, choose FI_UserManagement. Then, in the back end, create one SAP user (SU01 user) per Web user. Of course, these SAP users wouldn’t carry their own authorization data but would only be assigned to a reference user. The Web users inherit their authorizations exclusively from this SAP reference user, which means that they do not themselves have roles or a profile in the SAP system. The system transfers the reference user’s authorizations to the (Web) user of Biller Direct.

Now the Web user who logs on to Biller Direct is authenticated against the reference user’s authorizations — but how does the application know which invoices or customer master data to read? The system maintains the relationship between Web users and customer master records in transaction SU01 as well. You can create user references there by selecting Go To > References in the menu. Biller Direct provides an Internet view of your AR accounts, so you would normally assign a customer account to your Web users. Under certain circumstances you might need a more granular assignment. At the end of this article, I’ll describe some other implementation options.

The entire assignment in the SAP system consists of only two values: the object type of the business object repository (e.g., the customer account, BUS3007) and a key. For a customer account, the key would have the following form: (four characters) and . If your account numbers are alphanumeric, you need to write everything in capital letters. Let’s take two simple examples: You’d like to assign the customers 1111 and Miller in company codes 3000 and 3200. In this case, the correct account numbers would be 30001111 and 3200MILLER, respectively.

You can use Biller Direct for two different AR systems: Financials- Accounts Receivable (FI-AR) and Financials-Contract Accounts Receivable and Payable (FI-CA). FI-AR is the classic AR system; SAP developed FI-CA for processing large quantities of data (several million business partners), and various industry solutions use it. You need to select the right base configuration within XCM: I focus on the relevant settings for FI-AR in this article, so it would be FI-AR.

Now you’ve set up everything for the user management — once the system authenticates the user, it determines the relevant business partner (FI-CA) or customer (FI-AR). You can also assign multiple customer accounts to one Web user. Biller Direct does not mix the data (i.e., it is not possible to see on one screen open items from different customer accounts). Instead, the Java application displays an additional tab strip that allows Web users to switch between different accounts. The system saves the customers related to the Web user in table USAPPLREF.

If you run SAP CRM and mySAP ERP together, you might decide to set up XCM differently and choose the CRM_UserManagement configuration. In this scenario, you create all Web users and reference users within the SAP CRM system with empty profiles because the required authorizations aren’t available in the SAP CRM system. Within SAP CRM, you assign the contact persons or business partners to the Web user. In addition, you need to create reference users with authorization profiles or roles within mySAP ERP. After the logon, the system reads the customers and business partners and assigns them to the Web users from SAP CRM. Using the reference user now recognized by Biller Direct, the system reads the authorizations from mySAP ERP. The pool user carries out all processing because the system only created the Web user in SAP CRM. You need to set up the mapping between the business partner in SAP CRM and the customer in mySAP ERP in SAP CRM as well by assigning a business partner within SAP CRM as contact person for the customer in mySAP ERP. You can maintain the relationship between the CRM business partner and the mySAP ERP customer in table CRMM_BUT_CUSTNO.

If you decide to manage your Web users outside of the SAP system, you can choose the configuration UME_UserManagement in XCM. You should use this configuration if large numbers of users access Biller Direct, such as if you run a utilities company or if you’re a public sector institution. Again you have two options: You can create your Web users within an external database (e.g., SAPDB) or you access them from an external directory using Lightweight Directory Access Protocol (LDAP). LDAP was developed as an open standard for global or local directory services in a network and/or on the Internet. SAP designed the directories to support a high volume of queries, but the data in a directory should not change frequently.

In both cases, you can use SAP’s User Management Engine (UME) interface, which is part of the SAP Web Application Server (Figure 5). UME provides user administration, authentication, and user self- services. For example, you can create new users, change existing ones, lock or unlock users, and assign different profiles to them. In Biller Direct, SAP extended the UME user management screens with a section that allows the administrator to maintain Biller Direct-specific data. This screen becomes visible when you start maintaining users in UME. The specific data are:

• Reference user that holds the authorization profiles (fscm_refuser)
• Business partner object, (e.g., BUS1006 [objtype])
• Customer number, (e.g., 0000000211 [objkey])

Figure 5

User management engine

In this scenario, you create all Web users in an external LDAP server (Figure 6). After the Web user logs on, the system reads customers or business partners plus company code and reference users belonging to the LDAP Web user from a separate database. Using the reference user now recognized by the system, the system reads the authorizations from mySAP ERP and presents the information to the Web user. The benefit of this configuration is that the system stores only a few reference users (including their authorization profiles or assigned roles) in the SAP back end, whereas it saves the actual Web users in the LDAP directory or the UME database.

igure 6

User log on to Biller Direct with LDAP

After you select and configure the user management option that fits your needs, you must next decide how to enroll all of the Web users. You have two options: Either you inform your customers proactively about your new e-invoicing service (active enrollment) or your customers request users themselves (passive enrollment). SAP provides the report RFSCM_ACT_EN for FI-AR to notify your customers of the Biller Direct offering. You can include attributes such as customer number, customer name, country, minimum sales per fiscal year, and minimum number of open items on any key date for the customer selection. You can either print out and send the enrollment information or send it directly via email.

If your customers prefer requesting users by themselves, they can fill out an online form in the Web application. The only mandatory attribute on this form is the user name. However, to facilitate the later assignment of the person requesting the user I recommend you insist that your new Web users provide as much information as possible. Once the customer completes the form, the Web application sends the form to the back-end system using an Internal Service Request that creates a general notification (Figure 7) with the data that the customer enters. The service clerk responsible can call up the customer’s request in his notifications work list (transaction IQS8). If your customers send you a letter, fax, or email, the service clerk must transfer all data sent to him or her manually into the mySAP ERP system using transaction EBPP_CREATE_USER in FI-AR. Once you save the data in the system, the system automatically generates a general notification as well.

Figure 7

User request in the SAP system

I discussed the assignment of customer accounts to the Web users and I mentioned that this might not be sufficient for your business needs if you intend to implement a more granular assignment concept. I know of at least two typical customer scenarios in which such requirements arise. You might have set up the SD component and work intensively with bill-to, sold-to, and ship-to roles. Usually Biller Direct displays those invoices that belong to the SD payer role (and that actually correspond to the customer in the FI component). You could be interested in separating invoices that belong to different bill-to parties, for example.

In some industries, it is quite common that branches of a company sell their goods or services independently but perform the accounting for these sales centrally at the head office. You can represent this type of organizational structure in the SAP system by using head office and branch accounts, and can manage the sales orders in the branch account. The AR system does not post the sales and transaction figures to this account, but rather automatically to the head office account. The head office clears the payments, meaning that you can make outgoing payments for several branches in one step, using the head office account. With such a setup, you would need to display only those invoices to a branch account user that belong to a certain branch while the head office user could see all invoices for every branch.

SAP provides two Business Add-Ins (BAdIs) that FI- AR uses to implement this kind of scenario: EBPP_USAPPLREF and APAR_EBPP_GET_DATA. BAdIs are points in an object’s source code where you can insert additional functions or statements without having to modify the original. These interfaces are upwardly compatible and won’t be affected by an upgrade. In the first step, you need to assign all customers and sub- objects (e.g., branches or bill-to parties) to a Web user. This assignment varies depending on the implemented user management. If you maintain Web users in the SAP back end (FI-AR), you need to maintain user references via transaction SU01. The sub-objects have the Business Object Repository type EBPP_SPART (instead of BUS3007, for example). If you maintain Web users within UME, you have to assign sub-objects there.

In the BAdI EBPP_USAPPLREF, you create the account hierarchies and maintain the assignment of sub-objects to the superior Business Object Repository entities. You also create the structures of how Biller Direct should display these relationships. I’d recommend indenting all bill-to parties belonging to a payer account (Figure 8). In the method GET_USAPPLREF_TEXT of the BAdI EBPP_USAPPLREF, you can also maintain the text that displays for a sub-object (e.g., Branch office). Finally, you need to modify the selection of open items in the SAP back-end system by defining a dynamic WHERE clause in the method BEFORE_ITEM_SELECTION of the BAdI APAR_EBPP_GET_DATA. This avoids displaying the entire customer account when a Web user selects a sub-object (e.g., a sold-to account).

Figure 8

Selection of bill-to accounts

Juergen Weiss

Juergen Weiss works in the functional area of SAP Financial Supply Chain Management. As part of SAP’s product management team, he was globally responsible for the Financial Supply Chain Management applications, including Electronic Bill Presentment and Payment, Dispute Management, Collections Management, Credit Management, Treasury and Risk Management, Bank Relationship Management, and In-House Cash as well as Accounts Payable and Receivable.

You may contact the author at juergen.weiss@sepa-now.de.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.