Skip to Content

The biggest challenge for developers and solution architects is unthinkably the huge number of possible ways to solve any given problem. We usually don’t think of this because we have our habits to fall back on, but there are always more than one possible approaches to any given problem which requires a “more than workable” solution.

There is a better way to manage this vast complexity than by making big decisions up front and then hoping for the best. To make better solutions — solutions that are more functional and usable — we have to break our design problems up into small independent chunks based on the real issues within our requirements.

In this series of web logs, I’m going to show you how to use patterns to make better design decisions.

What are patterns?

Patterns have played an important role in architecture, urban planning, and in the field of software design in the contemporary world. In all of these cases a pattern is a way of dealing with a system of interacting forces. A dictionary.com search (http://dictionary.reference.com/search?q=pattern) reveals the following definition of the word “pattern” –

“A reliable sample of traits, acts, tendencies, or other observable characteristics of a person, group, or institution”

What are design patterns?

Design Patterns are time-tested solutions to recurring software design requirements. They are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges. They are given names and other properties, and are expressed as a commonly recurring class structure used to solve specific design problems. Their use encourages software developers to build systems that incorporate the good software engineering principles of low coupling and high cohesion.

Broadly, design patterns are categorized into three groups

  1. Creational
  2. Structural
  3. Behavioral


Without delving into the specifics on design patterns (you can anyways Google around to find more information), I would like to introduce one of the structural patterns called the “façade”, using a C# code snippet which uses the SAP .net connector to do RFM calls.

In general, structural patterns are concerned with how classes and objects are composed to form larger structures. The intent of the Facade Pattern is to isolate a subsystem from a client by placing the subsystem behind a simpler interface which exposes only the functionality that the client needs. In other words, a façade can also said to be a single class that represents an entire subsystem.

image

In our scenario, we would use the Facade Pattern to create a simpler interface for the proxy created by the SAP .net connector.

We start off by adding a new class to the project. (I’m assuming that the SAP .net Connector Proxy has already been added and the required BOs/RFMs are added to the proxy). We call this new class “BAPIholder”, because of the obvious reasons for which it exists.

image

Add a private member to BAPIholder of the type SAP .net Connector proxy and initialize the member in the class constructor.

image

Add a surrogate private method for initializing the connection on the SAP .net Connector proxy.

image

Now wrap the BO/RFM calls on the proxy into public scoped methods.

image

And voila, you have the façade ready for consumption. For the sake of simplicity, the code snippet only uses only a single subsystem (SAP .net connector proxy). However, you can extend the example to include other subsystems as per your requirement.

The need for the façade pattern on top of the SAP .net connector proxy arises on account of the following

  • The proxy generated by the SAP .net connector exposes many complex types, some of which may not be required by the client using the proxy. It may be a better idea to encapsulate these types and present a simpler interface to the client.
  • A simpler/unified interface would also allow centralized and efficient management of R/3 connections, connection attributes and connection pooling. This good coding practice would prevent the client code to be littered around with calls to the SAP proxy object.
  • It is also easier to debug and maintain the code because of the above stated reasons. Code reuse is also enhanced.
  • Within the façade, frequently accessed and static data may be cached to reduce the number of hits on the application server. Data from multiple data sources, viz. files, ERP systems, RDBMS, etc. may be consolidated and presented as a unified whole to the client. In such a case, the Cache/File system/ERP system/RDBMS, etc would also form the subsystems in the façade.
To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply