These instructions may be specific to my company's SAP environment, I am not really sure since I have minimal exposure to SAP outside of my company's environment. And, I am not a true SAP expert, so your results may vary.

When our shipping department creates a delivery in SAP we want to automatically generate printouts, such as for the shipping labels. We are able to accomplish this through the use of message conditions. When the delivery is created SAP checks the shipping point and the sold to party to determine if it should send messages to other parts of the system for further actions to be completed. Here I am only concerned with the print messages.

Procedure to view existing message conditions
Prior to making any changes I usually like to examine the current state, and this is the procedure to accomplish this. In transaction VV23, enter the output type (ZLnn), and then select key combination. In the key combination dialog select "shipping pt/sold-to P.". Next, there is another entry screen where I can select the "shipping point/receiving pt" or the "ship-to party". Once the desired criteria is entered and execute (F8) is clicked, all of the message conditions for the desired output type are shown according to the selected shipping information.

Procedure for creating a new message condition
The first steps for creating a new message condition are the same as for viewing, the primary difference is the initial transaction code. In transaction VV22, enter the output type (ZLnn), and then select key combination. In the key combination dialog select "shipping pt/sold-to P.". Next, there is another entry screen where I can select the "shipping point/receiving pt" or the "ship-to party". Once the desired criteria is entered and execute (F8) is clicked, all of the message conditions for the desired output type are shown according to the selected shipping information. Here it is possible to add another message conditions. Add a new line and enter the "Ship.point", the "Sold-to pt", the medium (1 for printout), the dispatch time, and the language. Once that is completed, the communication button is used to determine where the output will go. Select the output device or printer name, and the number of messages to send (the number of copies). Normally, we also select the "Print immediately" check box. Finally, click the save button store the new message condition.

Conclusions
Notice that the transactions are VV2n, and the V2 conditions are for shipping. So, if I want to modify handling unit message conditions which are type V6, I use the transaction VV62 (or VV63 to view the conditions. It's nice how these match up like that. Along those same lines there is: VV13 for sales outputs, VV33 for billing outputs, VV53 for sales activities, and VV73 for transportation.

I just finished reading a white paper from researchers at UC Berkeley's RAD Lab entitled "Above the Clouds: A Berkeley View of Cloud Computing", and my interest in cloud computing has been reinvigorated.

For a while I have believed that web based applications would eventually surpass locally installed software. Around ten years ago when Macromedia Flash 3 was released with JavaScript support I thought that I would be able to build some great online applications, but the technology really wasn't quite ready. Now, with technologies such as AJAX and client-side browser storage, the concept may be nearing critical mass. Seeing what Vivek Kundra did for Washington D.C. as their CTO certainly made me feel that large organizations could be ready for cloud computing. But, I know that before private corporations can implement the technology they must first understand it, which is why I feel this white paper is valuable.

The Berkeley paper establishes definitions that bound the scope of the associated technologies, which is very important. It frequently seems to be the case that whenever new technological ideas are being discussed and formed, vendors simply print out new stickers to slap on existing products in order to market them as leading edge technologies. And, if you consider that the use of cloud computing could reduce the number or size of data centers at major corporations, then you can start to understand why computer manufacturers could be threatened by this disruptive concept. It seems reasonable to me to expect that cloud computing providers would find efficiencies that could effectively cut into the lucrative corporate maintenance agreements that server manufacturers love. So, the paper offers knowledge for IT managers to defend themselves against vendor claims.

After the in depth definition of what cloud computing is and explaining why it's time has come, the paper goes on to present some obstacles and opportunities. The third obstacle, data confidentiality and auditability, really struck me. This has been the most common contradiction I have heard to the cloud computing concept. I have long felt that certain SaaS applications, such as Gmail, have provided better protection than similar in-house corporate solutions. But, when I present that idea the follow up response is usually that the company would loose control of their data. I usually quit debating at that point, as it seems to be a sort of straw man argument. And, arguing against their point would be viewed as criticizing their infrastructure or staff, and that would immediately make them oppose the idea even more.

I feel that in the long run some companies, probably smaller ones, will switch to cloud computing to reduce their overhead, thereby gaining a competitive advantage. Then, the larger companies will be forced to think hard about the value of controlling their own data. Maybe a recession will help to accelerate this process.

That is the part of cloud computing that I enjoy the most, the idea that cloud computing can effectively level the playing field for smaller, more agile software development companies. And, I think that this will further encourage innovation. I know that I will certainly continue to write applications for Google's App Engine, and maybe someday I will develop a real crowd pleaser.

Where I work we have a web application server that runs numerous business applications which are all connected back to a database server. Each application has it's own database and also shares read access to a database containing central data such as personnel and department information. The system, which I inherited, works pretty well, but it's architecture seems to be somewhat dated. As a part of my continuous improvements, I intend to start reshaping it.

Yesterday I wrote a post describing why I decided to switch from MooTools to jQuery, and today I have my first small comparison between the two. For one project that I am working on I have a simple autocomplete text input, and below I will show how I completed this little task in both MooTools and jQuery.

I am using plugins for both of the frameworks in order to accomplish this task, so this doesn't truly compare the functionality of the framework. But, this is a common task that I have and it starts to give me a feel for how the two match up.

The data returned from the server side script is different for each of these two methods. The MooTools Method gets an array returned, whereas the jQuery method gets the results returned as a newline delimited file (one autocomplete suggestion per line).

MooTools

jQuery

The Input Box


Update: 2009-03-31
While reading through the jQuery Blog, I found a nice plugin that is a “replacement for html textboxes and dropdowns, using ajax to retrieve and bind JSON data”. In other words, it's an autocompleter or suggest box. It is from Fairway Technologies and called FlexBox. It seems to be very powerful, check out some of the FlexBox demos.

Update: This is a really old post; I don't develop apps this way anymore, and I hope no one else does either.


I have been using the MooTools JavaScript framework for a while, but I recently decided that I would try switching over to jQuery. The impetus for this switch came as I was working to optimize one of my intranet applications for broader use.

I maintain many web applications that were originally developed strictly for use at what is now a division of a larger conglomerate. All of these ColdFusion applications are running on a single web server, and as our sister companies have become interested in using them I started to consider the implications of an expanded user base. After some analysis I concluded that, though these applications were designed for maintainability over scalability, the current equipment could adequately handle the expected load increase. Once I was confident that the local infrastructure could support an increased load I began to think about the clients.

One of the new facilities that will be using these web applications is located in Mexico, and available bandwidth to that location can get tight at times for a couple reasons. First, the bandwidth on the WAN going into that facility is less than what is available in the US. Second, the traffic is regulated so that the our SAP traffic gets the highest priority, and web traffic gets the lowest. Since bandwidth could be a concern, I started looking for ways to optimize my pages for size.

As I looked for ways to minimize network utilization a lot of ideas came up, the least of which was switching JavaScript frameworks. I have plenty of opportunities to decrease my network footprint. The first, and easiest step, was to compress existing files. The next item on my list was continuing to expand the use of AJAX (or more maybe appropriately AJAJ, as recently I have preferred the use of JSON over XML). In truth, switching frameworks would save me very little bandwidth. But, it was through the process of examining at the detail level what we were doing that I started evaluating JavaScript frameworks again.

For the most part, I was only using the framework to perform minimalistic DOM manipulations and XMLHTTPRequests. We never wanted the intranet web applications to appear too flashy, otherwise our internal customers would demand that we just give them a "basic" web page in half the quoted time. Therefore, I was not taking advantage of many of the great effects that MooTools offers. I understand that MooTools also offers easy ways to create and extend classes, but I have been using regular custom objects in JavaScript. So, it seemed that my spartan designs weren't taking advantage of MooTools perceived strengths. I just wanted a quicker way to access the DOM and some shielding from cross browser quirks.

So, it was from the perspective that MooTools was too sophisticated for my needs that I began to look for other frameworks. After looking at many frameworks (Dojo, GWT, jQuery, Prototype, YUI), I settled on jQuery. Not to say that jQuery is not sophisticated, it is just that jQuery seemed to focus on the aspects that I needed and left everything else to be loaded as a plugin. From a file size perspective, jQuery is only marginally smaller than the MooTools core version that I was using. From what I was reading, jQuery was supposed to be marginally faster than MooTools, but so far I don't have complaints about either.

Besides for technical considerations, there was one other factor that pushed me towards jQuery. The size of their community and the amount of corporate "endorsement" they seem to have. Normally I like to judge subjects on their merits rather than popularity, but the fact of the matter is that if I were ever to leave my company they would need someone to maintain the code. The larger the community behind a framework, the more likely they will be to find someone capable of managing it. Or, if nothing else, the next person who is responsible could find documentation online. I must say that I do personally prefer MooTools' online documentation format, but there just seemed to be more support in general for jQuery.

I am just getting started with jQuery, so it is possible that I could end up coming back to MooTools again. And, I am not ripping out all of the dependent code that we currently have, so I will be working with both and as I move forward I will document my progress.

One of my duties at work is managing shipping printouts, such as labels and delivery notes. And, a common task that I have had lately is printing out test labels or performing reprints, so I decided to write a post about the procedure I have been using in SAP to accomplish this.

First, I use the transaction SE16 (SAP data browser) to view the table NAST. I believe that the table NAST simply contains the output from messages. On the selection screen I enter the Application (KAPPL), which for me is normally either V2 (shipping) or V6 (handling units). Next, I select the Message Type (KSCHL), which is normally something like ZLnn. Then I am shown data that fits that criteria. The third column (OBJKY) on the entries screen shows delivery numbers (for V2 types) that have messages meeting my criteria. So, I copy one of the latest delivery numbers for the desired message type.

Next, I go to transaction VL71 (for V2 messages - it would be VL74 for V6 messages), which is to display output from deliveries. I use the default sort order of 01, enter 2 (repeat processing) for the processing mode, and then paste the delivery number from the previous step into the delivery box. F8 executes the transaction and gives me a list of message type. I check the message that I want to reprint and hit SHIFT-F5 (Edit - Print Default) to select the printer. Hit SHIFT-F2 or click the execute button, and the prints will be sent. I could also use the print preview button to save paper, but bar codes do not render properly in the preview.

I have come to the conclusion that many times business owners and managers unwittingly allow software programmers to determine their long-term technology strategy. Programmers are hired just to write software, so how could they be steering a business' technology strategy?

The explanation is really quite simple. Depending upon how the software is written and what tools are used in the process, it could be establishing some deep rooted dependencies. And, it seems that programmers are often given too much leeway in selecting their tools.

If a program is written with the intent of being installed on client computer, then there would be an obvious lock-in to the platform for which it was designed. It makes sense that if a program is written for Windows XP, then it will not run on OS X. Most managers would say that is acceptable since they must be currently using the system for which the software was designed. But, it has been my experience that software is always around for longer than the original designers intended. This was a major factor in the scare leading up to Y2K.

Furthermore, as people become more accustomed to using mobile computing platforms, their use will become more widespread and corporate software will be expected to become mobile as well. In my opinion this represents the most likely scenario where a company would want to use it's software outside of the platform for which it was designed.

There are ways to avoid platform dependencies. A cross-platform language, such as Java could be used. Or, as is becoming more common, application servers can be used. The most common application servers are web application servers. In a previous post I explained why I felt web applications represent the future of software applications, and more progressive managers are already looking to exploit web applications. But, just taking advantage of web applications does not guarantee that your software will be client independent.

I was recently talking to people from a company where they had two major web applications projects underway. One project was based on LAMP (Linux, Apache, MySQL, PHP), and the other project was being built with Microsoft based technologies. The LAMP based project was great, there was a LAMP server that the company had to support, but other than that there was no requirements. The application could be run from any modern web browser, on any platform. The Microsoft based project was also very good, it had a great interface and there were Microsoft servers on the back-end. But, there was one major problem that I saw. The application had to be run inside of Internet Explorer. So, with this project the company was paying a huge extra expense for the Microsoft technology, and they were locking themselves into using platforms that had Internet Explorer.

This situation is not a big deal now because Microsoft Windows is so ubiquitous. But, it severely limits the company's future flexibility. Ideally, a company could make all of their applications web-based, and then purchase dirt cheap netbooks with Linux on them. All they would need is a computer capably of surfing the web, and they could save a lot of money over time. But, because of the Internet Explorer requirement the company will forever be forced to maintain some sort of Microsoft licensed software.

The moral of this story is that you have to be careful with giving contracted programmers too much room to be creative. And, I am using the term programmers, but I also mean analysts and architects as well. Think of your strategy, think of the impact of client-side dependencies, and don't work with programmers who play down this issue.

Since I have had a lot of traffic going to my page on business cost saving ideas I thought that I would share other cost saving activities I have seen happening where I work. Our division has always pushed for generating and utilizing ideas from all levels within the organization, and the president is pushing everyone to come up with two cost saving ideas a month. He has set a goal that everyone in the company save two dollars a day. Our organization was lean to begin with, so now we are taking extraordinary steps to reduce overhead costs.

I work in IT, so I mostly see things that relate to information technologies. One big item that has been cut is printing. First, we removed almost all the color printers. Then, we started trimming down the number of monochrome printers. We have also switched to draft mode printing in order to save a small bit of toner on each print. And, I think that we have gone so far as to ask people to shake the toner cartridges to get every last bit of toner out of them. We also have reduced the number of business copiers that we have, which was a bigger savings since most of those fell under maintenance contracts.

Another huge expense is communications. The companies cell phone bill is in the range of hundreds of thousands of dollars, and they would like to at least cut it in half. We already have negotiated rate plans, so the next step was to simply reduce the number of phones. The first milestone was the elimination of all the floater and spare phones. After that each manager was asked to evaluate his employees' phone usage and take back phones from people who don't need them on a very regular basis. Now very few people still have corporate cellphones, not that the cellular companies should worry, as I have said before that reduction is apparently being offset by workers buying personal phones.

But, there are still quite a few people with Blackberrys. So, that is now one of our larger communication expenses, excluding the items that are hard to reduce such as dedicated lines. The company was always very strict on who would qualify for a Blackberry, so now comes the tough decisions. If the company pulls Blackberrys back, then they won't be able to get as much work from employees. But, it is tough to value that against the hard costs of paying for Blackberrys. I have suggested that our data security policy be loosened during these tough economic times so that the company may be able to have it's cake and eat it to. Currently, anyone who turns in their corporate Blackberry has no other way of accessing that type of data on the go. Even if an individual decides to buy his own smart phone, it is against our security policies to forward corporate communications to personal devices. Sure, an employee could ignore the policy and just do it. But, who is going to risk their job in order to help the company, that is a crazy predicament.

Moving to the topic of software, we are trying to reduce the amount of software that is installed. At first look, this may seem crazy, but so is life at a gigantic global company. The company purchased licenses for software, and most commercial software does not have associated maintenance fees, so there should be no ongoing costs. Right? Well, in our case the parent company in Germany manages all the software licenses, which itself doesn't make sense since the cost of software in Europe is frequently higher than it is in the US, but that's another topic. In any case, since the software is payed for at headquarters, they send us monthly bills for usage. Each software has a monthly fee for each installed copy. If an employee installs a piece of software for one day, his department will be charged for a month of usage. In order to reduce the amount of money that we are paying to headquarters we are trying to remove as much unused software as possible. Of course this could have a funny side effect. The parent company in Germany, who is feeling more financial pain than we are, may end up further in the hole if they can't act as quickly as we do to reduce what their overhead on this software. So, in the end, they may end up just charging us a higher monthly rate for software.

Our company also has larger software packages that require ongoing maintenance fees be paid to external companies. For these packages we are attempting to reduce the bill by dropping to lower levels of service. We may have server operating systems with service level agreements providing for 4 hour resolution windows, but because are systems are already redundant we may be able to get away with accepting a 24 or 48 hour resolution windows. This could drastically reduce our maintenance bills.

Our company is also doing everything it can to reduce energy consumption. The IT department has helped work towards this goal by finally utilizing the computers' inherent power saving features. We also encourage users to physically power down monitors and computers when they are not using them.

In general, we are doing everything we can do keep our money under our roof. The company fired the external cleaning company and now has internal employees perform the basics of that work. In IT we are drastically reducing the number of consultant hours used, which means that existing staff will have to learn some more varied and specialized skills. It also means that the business will have to go without some of the improvements it would like to see.

Those are the big actions that I can see occurring now, as I learn more I will write about what I learn.