SAP ABAP Training - ABAP Language 3

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.
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
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 Training - ABAP Language 2

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.
ELSEIF NOT (my_variable > 0).
And, here is a sample CASE statement:
CASE my_variable.
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.
IF sy-index > 100. EXIT. ENDIF.

ABAP also supports conditional loops:
Finally, ABAP supports looping against database or internal tables:
SELECT (conditions) FROM (database_table).

LOOP AT (internal_table).
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.

Recession Could Improve iPhone Sales

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.

Chippewa Lake Amusement Park

Chippewa Lake Amusement Park
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.

I wasn't sure what to expect, but most accounts said that it was possible to see some of the old rides from outside the fence. And, I wanted to take some pictures, but I didn't wanted to get busted for trespassing, so this sounded promising.

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.

Why Web Applications are the Future

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.

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.

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.

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.

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.

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:
(Óð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.


Job Comparator - Version 4

On Thursday I published another version of my job comparison tool. The new version allows for jobs to be publicly shared. At first this seems like a bad idea, most people would not want to share all of their salary information. But, organizations might want to. It could give employers and recruiters a good tool for showing prospective employees what they offer. Then a candidate could privately do a comparison to see how good job offer is based on actual data.

I also fixed a few minor bugs and made some minor enhancements.

Homebrew Drinking Rules

Every time I share my home brewed beer with my friends and family I always remind them of a few simple rules that they should follow for a better experience. Most people are used to commercially produced beer which goes through more extensive processing than is feasible for most home brewers like myself. I do not yet have facilities to carbonate prior to bottling, nor do I have an expensive filtration system. So, to receive the best taste possible from my beer I submit the following tips:
  • Do not drink this beer directly from the bottle. Pour it into a clean, room temperature, glass container. Do not use a container that has previously been used for dairy products. Dairy products leave a residue that prevents the formation of a good head. It takes approximately nine runs through a dish washing machine to remove this residue.
  • Pour the beer out of the bottle in one continuous movement. Watch for any sediment at the bottom of the bottle and stop pouring before it comes out. While this mixture of sugars and dormant yeast contains many B vitamins, it does not look pretty, it can cause flatulence in some people, and can be a mild laxative. Commercial beer is artificially carbonated and does not contain this sediment.
  • Keep beer cool (below 50° F). In order to naturally carbonate a small quantity of yeast is left in the beer. In warmer temperatures this yeast will continue to consume sugars and produce carbon dioxide. Excess carbon dioxide will cause excessive foaming when beer is poured and will eventually cause bottle explosions. Cool temperatures cause the yeast to go dormant and settle to the bottom of the bottle.
  • Keep beer out of direct sunlight. Exposure to sunlight or fluorescent light will cause beer to oxidize faster. Oxidation is what causes beer to get a skunky character. It is the result of a photo-chemical reaction with hop and sulfur compounds.
  • Some beer will exhibit chill haze (cloudiness) when cooled. It is caused by proteins left over from the brewing process. As the beer warms, the proteins re-dissolve. Chill haze is only a cosmetic problem. You cannot taste it.
  • Unlike wines, most beers should be store upright to minimize oxidation and metal or plastic contamination from the cap.