Event
Summary
To answer questions for a Technology Evaluation Center customer, a large utility
in the northeastern United States, TEC interviewed Dr. Peter Barth, Technology
Marketing Manager for SAP AG in Walldorf, Germany. Dr. Barth works for Corporate
Technology Marketing, where his main focus is basis technology, the Business
Framework and new technologies. After graduating from the Universities of Nancy
in France and Saarbruecken, Dr. Barth spent two years in management consulting.
He holds a Ph.D. in operations research and a Masters degree in computer science.
Question:
The customer was told that SAP is a fault tolerant environment, in that multiple
application servers can be configured and if one application server fails, the
client can connect to another one. Exactly how is this accomplished? Is the
failover manual or automatic?
Dr. Barth: The Central Message Server arbitrates client connections in
order to provide fault tolerance and load balancing. Clients are assigned to
"logon groups" which can be configured to attach to specific servers. When a
client attempts to connect, the message server will connect the client to an
application server that either a) has the lowest load, b) is specified for that
client in the configuration file, or c) a different application server if the
specified one is down.
TEC Analysis: The SAP system should be configured with multiple application
servers on different physical machines. The Central Message Server should then
be allowed to load balance.
Question:
What happens if the Central Message Server is down?
Dr. Barth: The Central Instance is a single point of failure. Some customers
have special precautions for the DB-server and also run the central instance
on it. Application transparent software fault tolerance can be accomplished
with products like Hewlett Packard Somersault. (For further information see
http://www.hpl.hp.com/techreports/98/HPL-98-06.asp).
Failover can also be automated, it does not have to be a manual process.
TEC Analysis: Hardware fault tolerance (i.e. RAID arrays or redundant power
supplies) should be implemented on the machine where the Central Message Server
resides. Software fault tolerance is also an option to be explored.
Question:
Our customer was informed that when a client connects to the Application Server
in SAP's three-tier architecture, a hard-coded "master" password which has been
configured during the installation of the product is passed between the application
server and the back-end database. Could that password be captured by a network
sniffer (a device which captures and analyzes network packets) and used to compromise
the security of the database?
Dr. Barth: With all the customers using SAP R/3, I have never heard this
question before. We will have to investigate it further.
TEC Analysis: TEC will vigorously pursue an answer to this question. Presuming
that the id/password combination used by the application server to the database
has DBO (database owner) level security, allowing an individual to capture it
would be highly dangerous. Encryption technology should be used by the customer
to code the network traffic. SAP does support Public Key Encryption products
such as Entrust. Customers who do not use network encryption could be at high
risk.
Question:
Is it possible to restore only a portion of the database schema using database
tools?
Dr. Barth: It is possible, but the DBA must be clear on what they are doing
because the referential integrity is program enforced within SAP. It isn't possible
to use database referential integrity because database referential integrity
can not enforce business logic. For example, payroll processing is workflow
driven. Errors are treated as exceptions to be handled later. In this scenario,
a database rollback would be useless. In addition, SAP provides tools to perform
tasks such as archiving data at the business process level (i.e. year-end close).
TEC Analysis: Program enforced referential integrity is necessary for an
ERP product. Database RI devices such as triggers and stored procedures could
never represent the complex business logic represented in applications such
as General Ledger or Payroll. Since the database does not contain all the requisite
information on table relationships, if the DBA is not entirely clear on the
table relationships then SAP tools should be used to restore data unless the
entire database is being restored.
Question:
Does SAP have a relationship with the Object Management Group?
Dr. Barth: Yes. We work with the OMG. SAP believes that metadata is very
important. We provide customers with the SAP Business Connector to produce XML
(Extensible Markup Language) mapping and conversion. We are also working with
organizations such as Biztalk. The database does contain a "business object
repository" where all objects are defined.
TEC Analysis: It would be useful for the SAP database to be completely UML-standard
based. This would make it easier for other data warehouse products to "understand"
the SAP schema. However, given that parts of the schema are proprietary (see
next question), this usefulness would be limited.
Question:
SAP contains three types of tables, transparent, pool, and clustered. Other
vendor's database tools can read only transparent tables. Should the customer
be concerned about this?
Dr. Barth: Pool and Clustered tables are used for internal purposes. The
customer should have no need to read them.
TEC Analysis: Extract/Transform/Load vendors have gone to significant trouble
to ensure that their products can access and read "non-transparent" tables.
TEC believes that this indicates customers do indeed have interest in them.
Question:
Is it possible to add database triggers to the SAP schema to assist in custom
event-driven actions?
Dr. Barth: Customers can and do alter the SAP schema. They can also add
triggers and the like. Once again, they must be clear on where alterations are
done and what they may mean. SAP provides SAP Business Workflow to, for example,
trigger actions with the help of a sophisticated event model. Customers should
not be worried about the physical representation of the database objects since
SAP is object oriented.
TEC Analysis: If the customer adds database objects, they may have difficulty
with SAP technical support if any errors occur. They must keep careful track
of the objects and what they are designed to accomplish.
Question:
Another ERP vendor has criticized SAP for having some of its most heavily accessed
tables not being stored in normalized relational tables. Do you consider this
an issue?
Dr. Barth: As you are probably aware, de-normalizing tables to reduce the
number of joins required to produce the desired results is a design issue, and
is often highly desired.
TEC Analysis: We agree with SAP's position on this issue. It is not uncommon
to de-normalize tables for efficiency.
Question:
On another note, a competing ERP vendor criticized SAP for implementing their
own database locking scheme, in addition to the locking done by the database.
How do you view this issue?
Dr. Barth: SAP implements locking programmatically to enforce business rules.
It would not be possible for the database to understand the Logical Units of
Work required for ERP processing.
TEC Analysis: Enforcing database locking schemes via the programs is sensible
due to the complexity of the logical units of work (a logical unit of work defines
a series of related transactions).
Question:
Is it possible to add indexes to the SAP schema?
Dr. Barth: Yes, sometimes it is even advisable for performance reasons.
Question:
The SAP Graphical User Interface (GUI) has been criticized by other vendors
as a legacy from SAP R/2, which was mainframe "green-screen" based. Other vendors
insist that their GUI's are richer in feature than SAP's. Do you have any comment?
Dr. Barth: SAP's GUI is very strong. Customer's can use the mySAP.com Workplace
HTML interface for access. The separation of the application and presentation
logic is important for performance reasons also within a web browser, and we
have always kept that in mind. Other vendors can be questioned on the degree
of response latency and the bandwidth requirements their graphical interface
requires.
TEC Analysis: Customers should keep the degree of physical and logical separation
between clients and servers in mind. Vendor benchmarks should be closely examined,
and tests run in the customer's real-world environment. The functionality and
performance of a user interface need to be evaluated on-site.
Question:
What method does SAP recommend for changed-data capture from its system to data
warehouses, particularly if the customer is not using SAP BW?
Dr. Barth: SAP BAPI's (Business Application Programming Interface), provided
access to the data and with SAP Business Workflow can be used to publish/subscribe
changed data. Capturing changed data should always be accomplished via a "push"
technology, not via "pull." SAP Business Workflow can be used to accomplish
this.
TEC Analysis: If at all possible, it is recommended that changes to the
database be "pushed" out to the data warehouse. "Pulling" data would require
that all the tables be examined for deltas, which requires an extreme amount
of overhead for queries on the ERP system.
Question:
How does a customer migrate code from test to production environments?
Dr. Barth: SAP provides a transport mechanism with the base product to perform
this task.
TEC Analysis: The ability to "promote" code from test to production test
to production is an important feature that should be examined carefully by the
customer's programming staff.
User
Recommendations
Customers
should carefully review the features of ERP products that they are considering,
including how the client/server architecture is designed. Often customers are
focused on the functionality of the modules in question and fail to recognize
issues regarding two-tier versus three-tier architecture, security, and database
administration. All of these issues should be examined in detail with the customer's
database administrators, network administrators, and others concerned with the
corporate infrastructure.