Skip to Content

What is Basis Anyway?  And Why is it Important?

If you scout through enough SAP technical information, or if you attend presentations at SAP events and conferences, or listen to webinar’s on SDN, eventually you come across it.  Especially with NetWeaver.  I’m certainly guilty myself of blithely uttering it.  That is, we often use the expression “proven SAP Basis technology” or something like it.  But we never go on to explain what this basis technology is, or why it is important.  We (wrongly) assume that, since it’s been around for so long, that everyone knows what it is.  It is not the hot, new Java technology that is so “sexy.”

But as my colleagues and I have recently experienced, there are many new people learning about SAP who have no idea what SAP Basis is.  We talk about “bringing SAP technology and experience to the Java world” but then do not follow up with what that technology is.  For some audiences (like an intermediate or advanced audience at TechEd), this is no problem.  But I am here now to elucidate to people who may not now about what this basis stuff is and how it applies to today’s world.

SAP Basis

SAP Basis is the foundation for the Web AS.  It is the technology that powers the “ABAP world.”  With the addition of the Internet Communication Manager and J2EE engine to the SAP Basis layer, the basis layer itself ceased being a technology bound to the application that runs on it and became a separate component itself – the SAP Web Application Server.  Many people have downloaded the Web AS from SDN.  But this is just half of a two personality server.  The full Web AS includes the ABAP engine (think of the famous conjoined twins, Chang and Eng Bunker).  And much of what we are doing in our J2EE server we have done for years in the ABAP server. 

Let’s start with the basis architecture.  The “work” in a SAP ABAP system is performed by, naturally, work processes.  These processes are specialized in nature and each only performs a certain kind of task or tasks.  The seven kinds of work processes are:

  • Dialog – responsible for processing direct user interaction through a UI
  • Update – responsible for making database updates
  • Enqueue – responsible for database locking
  • Background – performs background processing
  • Message – The system’s traffic cop.  Responsible for central communication between all work processes
  • Gateway – responsible for communication between work processes and external programs, as well as communication between work processes from different instances or SAP Systems.
  • Spool – responsible for printing tasks

Since the processes are specialized, they can both work and be configured differently.  For example, a dialog process is likely to have a short time-out period and certain limitations on how much memory it can use.  Whereas a background process will have a very long time-out period and not only will it have different limitations on how much memory it can use, it will use that memory differently.

You may say, big deal, so what…  But the real magic that drives the SAP technical architecture is not only the way that work processes can be configured, but how they are distributed.  The processes may be spread out among many instances and servers and this provides redundancy, fault tolerance, high availability and performance. 

How’s that?  How does it do all of those things?  It starts with the message service and enqueue service.  There is only one each of these in a SAP system and the instance they reside on is called the Central Instance.  All of the other work process may be spread out in any number amongst any and all the instances in the system, called application servers.  An application server may be dedicated to all background processing, for example.  Also, groups of users can be directed by the system to particular application servers when they log on.  This allows the buffers of a server to be filled with information for transactions that are continually running on the server, so that the transactions perform better since there is less flushing of the memory and retrieval from the database. 

Plus, in the message server’s role as a traffic cop, it can instantly notice when a server goes down (for planned or unplanned reasons) and redirect any new activity to the remaining servers.  This provides almost transparent fault tolerance and high availability to the end user.

Development

By now the systems people may be happy, but what about development?  Much of the above may mean nothing to a developer, but part of it both the developers and system administrators can be happy about.  That is, all of the runtime occurs in processes, not threads.  The systems folks are happy since when something goes wrong and a program crashes, usually the worst that happens is that a user session is terminated (the work process dies), but the server continues to run.  The developers are happy since they can take oodles of time to debug some code and they only lock up one process, not the runtime of everybody’s environment. 

But there is magic in the technology for developers as well.  Those familiar with ABAP know quite well that there has long been a centralized mechanism for enterprise software development.  It’s called the Change and Transport System.  The CTS helps keep track of object names, versions and locations.  When a developer creates or changes an object, it is checked-out and locked to prevent further conflicts and then all changes are recorded.  This allows any and all versions of an object to be accessed at any time.  Plus it makes it easy to subsequently distribute changes from development downstream to testing, training and finally production systems.  In addition to custom code and customer development, the architecture also allows for the efficient propagation of SAP Support Packages and upgrades as well.

ABAP itself is a central piece of the architecture, too.  With ABAP, a developer only has to be concerned with code, not the syntax of the Native SQL of a particular vendor.  The ABAP engine has complete database and operating system abstraction.  Code is easily portable to any of the database and operating systems that SAP supports.  ABAP also uses the modelling approach to development through the Dynpro, which separates frontend UI logic from backend business logic.

So?

Sound familiar?  By now I’m sure you can see the parallels to the SAP J2EE engine.  The new cluster communication architecture of the 6.40 J2EE engine resembles the communication, locking and work process structure of the ABAP basis layer, giving the java server scalability and high availability.  The new SAP Virtual Machine Container (as seen on TechEd) mimics the ABAP work process technology, and they have the same advantages.  The CTS and the Java Development Infrastructure are similar concepts.  The Web AS Java also provides DB and OS abstraction for all of the SAP supported combinations.  The Web Dynpro is an extension of the Dynpro.

Much of this may be new to the java world, but SAP has a bit of experience with it.  When SAP introduces a technology that extends the J2EE standard you can rest assured it is for good reason.  SAP brings the wisdom learned from running development and applications at the enterprise level for years, with thousands of productive installations. 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply