As with most technical SAP classes, the instructor began by explaining SAP's three tiered architecture. I relate the three tiered architecture to the MVC (model-view-controller) paradigm, it is just on a larger scale. SAP holds the model in database work processes on the database server, the view in the SAPGUI on the clients PC, and the controller is the ABAP programs that we will be writing on the application server. Database access is abstracted on the application server by the use of SAP Open SQL, which is converted to native SQL for the various databases that SAP supports.

After giving an overview of how SAP systems are setup, the next basic SAP topic is that of mandants. Everyone who uses SAP is familiar with mandants, but most people have no clue what it really means. Mandants were originally used for separating companies on time sharing servers. Two companies could use the same server to run SAP and mandants would keep their data completely separate. This seems a little dated, but technology is moving back towards time-sharing via cloud computing, so it may be more useful again.

Every client specific table has MANDT as it's first column, which contains the mandant. Development objects are client independent so that they can be used across all mandants, and thus have no MANDT.

Development objects, such as packages are kept in the repository, and you can access the repository information system using transaction SE84. But, if you want to see the hierarchy for an application you would use SE81, and if you want to see the data dictionary you would use transaction SE11. All of these transactions are generally required for writing ABAP programs, though the main ABAP programming transaction is SE80, the object navigator.

Like everything in SAP, writing and storing ABAP programs is very structured. Generally, you can't just start writing a program. First, a package is created from a change request, and inside of the package is where the SAP applications are written. There are three types of packages. The structure package is for organizational purposes and contains other packages. The main package falls under a structure package and contains standard packages. Standard packages are where actual programs are created and stored. The program code is stored in the database when you click save in SE80, then it is compiled into executable code when you click the activate button. Therefore, a program cannot be run without first being activated. Furthermore, a program requires a transaction code in order to be of use to users.

An ABAP statement always begins with a keyword and ends with a period. There is a little quirk caused by using the period as a statement terminator, floating point numbers must be enclosed in single quotes as if they were strings. Otherwise the period would be treated as a statement terminator and you would receive an error. This was probably not a big issue when the language was originally developed since in Germany commas are used as the decimal separator.

In ABAP, any line that has an asterisks (*) in the first column is considered a comment line. To place a comment at the end of a line you must use double quotes ("). Multi-line comments are not supported.

ABAP is a typed language, meaning that variables and their types' must be declared before they can be used. There are elementary or simple variables, structure variables which contain simple variables, and internal tables which contains structure variables.

Since keywords are determined by position there is no technical restriction on using them as variable names, but best practices dictate that this should not be done. The only restriction on variables is that they cannot be longer than thirty characters. SAP has ten standard variable types. Of these types there are two categories: complete and incomplete. Complete variable types are completely defined by themselves, whereas incomplete variable types need some additional information to be properly defined. Incomplete variables must have some sort of specification on the length of the variable.

• D -- an 8 character date (complete)
• T -- a 6 character time (complete)
• I -- a 4 character integer (complete)
• F -- an 8 character float (complete)
• STRING -- a string of characters (complete)
• XSTRING -- a hexadecimal string (complete)
• C -- characters (incomplete)
• N -- numeral (incomplete)
• X -- hexadecimal (incomplete)
• P -- packed number (incomplete)

It is possible to define local variable types in an ABAP program, but these are only valid within the program in which they are defined. The data dictionary (transaction code SE11) must be used to define custom variables types if a broader scope is desired. To define a local type within an ABAP program the following syntax is used:

TYPES my_new_type TYPE C LENGTH 5.
TYPES my__type TYPE P LENGTH 3 DECIMALS 2.

The default value for numeric variables is zero (0), and the default for character types is space ( ). Strings do not have an initial length, so the default value is not space. To set a default value the value keyword is used, this is shown in the following constant declaration. Below that are two variable declaration statements.

CONSTANTS my_const TYPE STRING VALUE 'my val'.
DATA my_float TYPE F VALUE '12.34'.
DATA: my_integer TYPE I VALUE 1234,
my_characters TYPE C(3) VALUE '123'.

When making variable assignments in ABAP, SAP tries to convert the source type into the destination type. SAP has 62 conversion rules that it follows when doing this. There are two methods for making variable assignments. In both of the examples below variable_two is assigned to variable_one:

MOVE v_two TO v_one.
v_one = v_two.

In order to reset a variable to it's default value ABAP provides the CLEAR keyword.

CLEAR my_variable.

For arithmetic expressions ABAP provides the COMPUTE keyword, however it's use is optional. Compute supports the following operators: +, -, *, /, ** (exponentiation), DIV (division without remainder), MOD (remainder of division).

COMPUTE my_v = another_v * 5 / 100.
my_v = another_v * 5 / 100.

SAP ABAP supports modularization by implementing subroutines and functions, and since it was modified to be object oriented it also supports methods. Subroutines are local to the ABAP program (technically they can be called form other programs, but this is only for backwards compatibility and should not be used), while function modules are shared. Methods can be either local as part of a local class or shared as part of a global class.

A subroutine has the following format,

FORM form_name.
(actions)
ENDFORM

and is called thusly.

PERFORM form_name.

The format above is simplified, and not very useful. Most likely the subroutine will need to have variables passed back and forth, below is the extended syntax.

FORM my_form
USING
value(variable_one)
CHANGING
value(variable_two)
variable_three.
(actions)
ENDFORM.

In the above example variable_one and variable_two are passed by value, whereas variable_three is passed by reference. The USING section is for read-only variables, while the CHANGING sections is for variables which will be modified.

SAP ABAP supports two types of conditional expressions, IF/ELSIF/ELSE/ENDIF and CASE/WHEN/ENDCASE. Here is a sample IF condition:

IF my_variable IS NOT INITIAL.
(actions)
ELSEIF NOT (my_variable > 0).
(actions)
ELSE.
(actions)
ENDIF

And, here is a sample CASE statement:

CASE my_variable.
WHEN 'ONE'.
(actions)
WHEN 'TWO'.
(actions)
WHEN OTHERS.
(actions)
ENDCASE.

For looping, ABAP supports four different types. The first type is the DO/ENDDO, which has two variations. Notice that I use the sys-index variable in the IF condition, this is a system variable that counts how many times this loop has run.

DO
IF sy-index > 100. EXIT. ENDIF.
(actions)
ENDDO

DO n TIMES
(actions)
ENDDO

ABAP also supports conditional loops:

WHILE sy-index <>ENDWHILE

Finally, ABAP supports looping against database or internal tables:

SELECT (conditions) FROM (database_table).
(actions)
ENDSELECT.

LOOP AT (internal_table).
(actions)
ENDLOOP.

Along with sy-index, SAP has 170 other system fields (171 total). Some important or frequently used ones include: sy-mandt, sy-uname, sy-langu, sy-datum, sy-uzeit (time), and sy-subrc.

Another common task is producing dialog messages, in ABAP the followign syntax is used:

MESSAGE tnnn(message_class) WITH variable_one variable_two variable_n

The with statement is for including variables from you program into the message, and is optional. The 't' that proceeds the message number ('nnn') is the type of message to be displayed, below are the options.

• i - An informative message that appears as a modal dialog, the program is continued after it is displayed.
• s - A status bar message on the next screen.
• w - A warning message that appears in the status bar
• e - An error message that appears in the status bar
• a - An abort message that appears as a modal dialog box, the program terminates after it is displayed (and the users confirms).
• x - A short dump is generated as a runtime error, you probably don't want the user seeing these.

It sounds a little counter-intuitive, but I think that Apple will sell more iPhones due to the recession. In a previous post I mentioned that I thought companies could save some money by giving employees incentives to use their own cell phones. To reduce costs at my company, people who do not use their corporate cell phones frequently have been asked to simply turn them in. For some this was no big deal, they were thrilled to only have to carry one phone around. But, there were a few people who only had a company phone, they didn't use the phone much and their limited personal use was acceptable.

Now these people are in the market for personal cell phones because they understand the importance of them in the modern world. I know some people who will not stop to help out a stranded motorist because they figure that the person should have already called for help on their mobile phone. Couple that with the disappearance of pay phones, and it becomes almost a requirement to carry a cell phone.

So, for the staff members that turned in their corporate phones the question becomes which phone to get. I know of at least one person who researched available phones and went with the iPhone because of all the features it elegantly packs in one device. Sure there are other phones that offer comparable features, but many of those just look like corporate phones and are certainly not as elegant. If you are going to have to pay for your own phone then it seems reasonable to purchase a phone that clearly illustrates your independence. I mean, if the company takes away a person's phone and basically forces them to go buy your own, would they really want to buy one that looks like a corporate phone? That would make them look like a bit of a sucker. They would be purchasing with their own money what the company is giving away for free to more needing employees.

Purchasing a clearly non-corporate phone, like the iPhone, can give the person a feeling of control over their destiny. They can say that they wanted to turn in their phone so that they could get a great phone that is not part of the corporate standard. Of course Apple is positioning the iPhone to be a corporate phone, but I don't think that would dull the sexiness of the iPhone.

I know another individual who is in the market for a cell phone because of turning in his corporate phone, but it's hard to say what he will end up purchasing. He keeps doing research on prepaid phones, but always ends up comparing them with the iPhone. I think that he would like to simply purchase an iPhone but hasn't convinced himself that the monthly service charges are worth it, especially given the current economic crisis.

So, in my little slice of the world, Apple is gaining business from the recession. With a little more research it may be possible to identify other businesses that will benefit from the recession by picking up consumer customers that have been stripped of their corporate perks.

A few weeks ago when we were Christmas shopping, my wife and I bought the book Weird Ohio, which had a lot of interesting stories about strange places in Ohio. We bought the book because we just plan on traveling around Ohio for our family vacation next year, and this would give us some more ideas on what to see. I was reading through the book and saw a lot of interesting places not far from Akron, including the Chippewa Lake Amusement Park.

I had heard of this abandoned amusement park before, but never had the chance to go see it. So, I mentally marked that as someplace I'd like to go see and then forgot about it.

Then, yesterday I read an article about five modern abandoned cities, and that made me think of the Chippewa Lake Amusement Park again. So, I decided to do a little more research on the park. I found out that the land has been sold to developers who plan on turning it into an 80-acre development called Chippewa Landing. So, I though that I better go visit the area before the wrecking crews get to it.


My oldest son and I made the half hour drive over to Medina county and started to look for the park entrance. Right off of Lake Road in Chippewa Lake we saw a street that was divided by a small concrete median with an old block sign frame on it, this was Main Street. We had a feeling that was the right road, so we turned down it. Next, we spotted some old street lights on the side of the road that looked liked the belonged at an amusement park, so we knew we must be close. Then, right in front off us we saw the roller coaster. It was locked behind the gates of a chain link fence with what seemed like hundreds of no trespassing signs. We respected the signs and just stood outside of the gates and took some pictures.

As we moved down the fence looking for a better angle to take photographs we started noticing the numerous holes in the fence. We were tempted to walk inside and take a look around, but decided better of it.

After checking out the main entrance, we decided to drive down some other nearby streets that seemed to dead end into the park property. On the next street over we were presented with a view of the rest of the roller coaster we had seen at the main entrance. It was quite impressive to see such a great structure rotting in the woods. It is hard to make out in the picture at the top of the post, but the curving vertical line is the tree entangled roller coaster.

I had seen some interesting photos of this old park on the internet, like ones of the old Ferris wheel, but those areas were not visible from outside the fence. It would be nice to be able to get some photographs of some of these rusting relics before the land is cleared, but I doubt that the owners would be willing to take the risk of having people walking around the decaying structures.

If you are interested in old curiosities like this, then I suggest you swing by and take a look before they tear the old place down.

Update: This post was written in 2008! So long ago. By now even the dustiest old IT manager knows about enterprise enabled SAAS solutions in the cloud.


It is largely assumed that most people know, as younger people know, that web based applications are the future. But, there are still many people, especially in large corporate environments, that I don't think fully appreciate this. Or, if they intuitively know that the web is the future, they don't understand why or how to get there in their enterprise.

When I speak of large corporate environments I am speaking of corporations that are not focused on developing software, large manufacturing corporations who use custom software to gain competitive advantages and therefore do not sell the software they develop. That is the type of company that I work for, so it is what I am most familiar with.

Background
I have been struggling to get a web based application development strategy implemented at my company, but to this point have not been successful. I feel that there are a few reasons for this. First, we are a manufacturing company and have had a stated goal of not developing software, so management largely turns a blind eye to internal software development. This has also caused software development to become somewhat decentralized outside of IT, and further complicates the issue. Second, we have so many legacy applications that the limited development resources are consumed with maintenance activities. Of course, in our case, this is really a symptom of a lack of strategy in general. And, finally, the point of this article, the management does not appreciate what web applications would do for them over traditional applications.

At my division of our company, our IT management decided many years ago to move to a strategy of utilizing intranet applications. The impetus for this switch was that users were creating applications that quickly grew outside of their ability to design and support, so IT was doing more work supporting poorly designed, user generated application. In many cases users would start by creating a simple Excel document, and as the scope grew they grew the complexity in their Excel spreadsheets. Once they reached the limits in Excel they switched to Access and began growing their application there. There is where the problems started coming for IT. Microsoft Access is not inherently scalable, and performs poorly over a WAN. So, the user solution was to create multiple copies of their Access databases. And, when IT got involved to assist with problems we would have to fix the problem multiple times for each copy of the original. Furthermore, the Access applications themselves were not initially designed for scalability or extensibility, so fixing issues was overly complicated. Therefore, IT made an upfront investment of rewriting these applications for the intranet in order to save time in the long run. And, that strategy has worked well.

In another division of our company they ran into the same issues with user created applications, but decided upon a different solution. Their decision was to create what amounts to a custom client-server version of Access. This worked well inside of the facility in which it originated. But, as it grew, problems with scalability began to appear. The program was still sending large amounts of data across the network, like Access. And, as the number of user of the application grew it started running out of server resources. The server portion of this custom application was designed to be scalable across server, but it had never been fully tested and it's designer had long left the company. So, this strategy did not resolve all of the problems exhibited by Access.

These two strategies were created before our divisions were brought under the same corporate umbrella. Now, we have two competing strategies for handling internally developed applications in North America, three if you include the official strategy of ignoring it. I, of course, am a proponent of web-based applications. So, I will explain why these types of applications are the proper approach in my opinion, and why I feel that the represent the future.

Fungibility
In my opinion one of the greatest strengths of web pages is that the server is detached from the client and they communicate via standard protocols such as HTTP, HTTPS, and FTP. This flexible interchangeability on both ends of the connection certainly drove the popularity of the Internet to it's current ubiquitous state.

Any type of client hardware which supports these protocols can use a given web application. In practice, any hardware with a web browser can utilize a web application. Web applications are considerably "future proof" as next year's client hardware will likely still support web technologies. This gives a business flexibility when choosing which operating system or hardware they would like to use for their clients. Our company has a team of people who are constantly evaluating which IT hardware we will deploy, they have to be sure that the hardware they select will run the various applications that our business has. This process could be simplified if they only had to verify that the hardware came equipped with a modern web browser.

The infrastructure itself can also be changed. In theory, Microsoft's IIS could be replaced with Apache or some other web server. In practice this switch is not so simple, the server-side scripting language and existing data would have to be considered, but it is possible. This allows the technology services or infrastructure people to have flexibility in choosing their operating system as well as the physical hardware. It also opens up the possibility of outsourcing server space as well.

In my mind, web servers and web clients can be somewhat treated as a commodity, assuming that established standards have been used when designing the applications that run on them.

Maintainability
Properly designed web applications require no additional software on the client equipment. There is nothing for the IT department to update, install, and distribute on a regular basis. When changes are made to a website's structure, standard redirection techniques can be used on the server, no changes are required on the client computer.

Our company also has a team of people who update software packages and make sure that the latest versions of software are distributed. Switching to web-based applications would reduce this load.

Scalability
Properly designed web applications are inherently scalable by simply using standard network and web server infrastructure. There are numerous methods for spreading the load of a web based application, the specific strategy would depend upon the intent of the applications being used, but here are some example cases.

If a web server becomes saturated with requests on a regular basis, then another web server can be added that is basically a copy of the original. The DNS records could be updated to list both servers for the given web address, and users would be randomly spread over the different actual servers.

If an application is serving a lot of media, such as images or videos, then special servers could be set up just for serving up the large static content.

Conclusion
It seems that there would be an upfront cost to selecting a web application strategy, but it would pay off in the long run. A company might have to hire more skilled web technologies programmers, but it could possibly reduce the number of people supporting server and desktop computers. The business wouldn't have to spend as much time on IT overhead items like selecting hardware and upgrading software, it would spend more time on developing solutions that help it be more competitive. The keys to this strategy would be finding the right web technology developers and having a manager who understands the strengths of web technologies and is able to exploit them for the company's benefit.

My Imitation Christmas Ale is nearly nearly ready to serve. I have begun to bottle it, so now it only needs to condition for about a week in order to build up a proper level of carbonation. It's a light amber color with a slight amount of haze. My experiences brewing mead leads me to believe that at least a portion of the haze is from the honey. And, since real Christmas Ale is not crystal clear, I don't feel that this as a flaw.

As an experiment, I will reserve one gallon and let it lager for a longer period of time. I have a feeling that as the more complex carbohydrates in the honey are consumed by the remaining yeast it will become more clear. The alcohol content should also go up somewhat, but I am more curious as to the taste after lagering.

I have named this years recipe Odinzale, in honor of the Norse god Odin who may be the original ancestor of the modern day Santa Claus. My wife picked the name, and I created a new custom label for it. The description from the label follows:

Odin
(Óðinn, Wōđanaz, Wōđinaz, Wōden, Wodan)
Odin, the chief god in Norse paganism, is most likely the original ancestor of modern day Santa Claus. Odin was described as a tall old man with a long white beard. During the frigid nights of Yule he would ride his eight-legged horse through the sky, punish the evil, and reward the good. The Norse, looking to copy Odin's generosity, exchanged gifts during Yule. Norse children would fill their boots with carrots or straw and leave them near the fireplace as a gift for Odin's horse Sleipnir. In return Odin would leave gifts for the children.

If you are one of my friends and family who gets a sample of the brew, please kindly leave me a comment below to let me how it tastes for you. I appreciate any honest critique, just let me know how you stored it (in the garage, in the refrigerator, etc.) and how it was served (ice cold, 50 degrees, in a glass, straight from the bottle, etc.).

And, remember to read my homebrew drinking tips.

Enjoy!