Christopher
Stoll

Enterprise Application Architecture

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.

With the current architecture, each web application manages all data access that it needs. Even access to the central data is managed by the specific application. There are some libraries that we have in place to ease the management of this, but the situation can still get difficult when we have to change the format of data in our central repository. Up to this point we have not had any data in the central database that could not be shared amongst all applications, but at some point in the future this may be necessary and would be hard to manage under the current situation.


It would be nice to move to a more service oriented architecture (SOA) approach in general, but the current economic conditions have put a damper on innovative solutions that could be costly or are even perceived as being potentially costly. So, I have been contemplating taking just the intranet systems that I am responsible for and implementing a web services based SOA approach.


It seems that this approach would be fairly easy to implement with each incremental improvement we do to the systems. First, we would write a web service provider, or a web application that serves no other purpose than accessing the central data. This application would then be responsible for controlling access to the central data. Then, as we make improvements to the existing applications we remove the portions of code that allow for direct access to our central data and replace it with calls to the new web service. The applications will still store the data (data keys) back to their respective databases, just the selection lists and details will come from the central data web service.

Autocomplete: MooTools and jQuery

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

<link href="mootools/autocomplete/Autocompleter.css"
    rel="stylesheet" type="text/css" />
<script type="text/javascript"
  src="mootools/mootools-1.2.1-core-yc.js">
  </script>
<script type="text/javascript"
  src="mootools/autocomplete/Observer.js">
  </script>
<script type="text/javascript"
  src="mootools/autocomplete/Autocompleter.js">
  </script>
<script type="text/javascript"
  src="mootools/autocomplete/Autocompleter.Request.js">
  </script>
  
<script type="text/javascript">
  document.addEvent('domready', function() {
    var networkcompleter =
      new Autocompleter.Request.JSON('ac-network', '../list/network', {
        'minLength': 2,
        'indicatorClass': 'autocompleter-loading',
        'postVar': 'q'
      });
  });
</script>

jQuery

<link rel="stylesheet" type="text/css"
  href="jquery/jquery.autocomplete.css" />
<script type="text/javascript"
  src="jquery/jquery.js"></script>
<script type='text/javascript'
  src='jquery/jquery.bgiframe.js'></script>
<script type='text/javascript'
  src='jquery/jquery.autocomplete.js'></script>

<script type="text/javascript">
  $().ready(function() {
    $("#ac-network").autocomplete('../list/network', {
      minChars: 2
    });
  });
</script>

The Input Box
<input type="text" class="textlong" id="ac-network" name="ac-network" />


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.

Switching from MooTools to jQuery

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.

Comments (newest first)

stollcri
Thanks for the great tips. I have been using the YUI compressor, which is good, but makes it difficult to troubleshoot issues in the production environment. I would like to switch to gzip compression on the server as suggested, it's just a matter of convincing the server guys (everyone has a full plate lately with the cutbacks in our industry).

Some of our users have no access to the Internet, so I don't know if using Google's APIs would work for our intrant applications. But, I have never used those and am interested in at least trying them out.

Thanks again for the advice!
Bob
I'm a mootools user, but I also plan to switch us over to jquery at some point... whenever we have a little resource bandwidth. The bigger community is crucial, and mootools just hasn't treated their community very well.

Also, if you're not already, you should be using google's ajax libraries api and letting them serve your framework javascript directly. As more websites use this, it's very likely that your users already have the framework cached in their browser. With the popularity of jquery, it's almost a certainty (assuming your users are free to visit other websites).
keif
I have to say - it's admirable that you're thinking *long term* and veighing on a future replacement's likelihood of understanding jQuery based on its popularity.

I've been big into MooTools myself, and have played with jQuery - it takes a little bit of digging in the docs to figure out how to duplicate your code between the two, but it's not impossible or overly difficult.

That being said, have you looked into gzipping your JavaScript components for an added squeeze? I've noticed I can often use and uncompressed JS file (with all my notes and comments explaining how it works) and gzipping it makes compressing it almost irrelevant (unless you're trying to squeeze every kb you can, in which case yui-compressing with gzip makes sense).

Best of luck!

Creating SAP Label Reprints

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.

Comments (newest first)

Christopher Stoll
By the way, you can also reprint messages from application ME (Inventory management) using transaction MB90 (Output from Goods Movement).

Programming Your Technology Strategy

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.

Cost Savings Follow Up

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.

Google Apps for NortonSoccer.org

This weekend I finally had a chance to migrate the nortonsoccer.org domain from the old static hosting provider over to Google Sites. And, I am quite pleased with the results. Now, the Norton Amateur Soccer Club is using the full compliment of Google services. And, since they are a registered not for profit organization, Google generously donates all of the services for no charge.

There were a couple of reasons that I wanted to move the website, the most important of which was that I wanted the content to stay more up to date. Previously, changes would have to be submitted to me and I would update the site as soon as I had time. Now, authorized members of the organization can update the website on their own.

The new website now has some great new features. There is now a site search that will allow visitors to quickly search the site to find specific content that they are looking for. There is also an embeded calendar, which functions much better than the previous bullet list of important dates. And, each of the sponsors now has their own page on the site, so the board could add additional information about the sponsors and provide them with greater value for their sponsorship dollars.

The new site did lose a few features, but through Google Analytics I knew that these features were not really being utilised much. One of those missing features is the photo gallary, but this will be coming back online once I set the club up with a Picasa web account.

Along with setting up the new website, I also set up the club to take advantage of Gmail for their domain. Now each of the board members has their own email address (e.g. president@nortonsoccer.org), and when people leave the board the new members should be able to quickly pick up where the last left off.

Finally, I am also quite proud of the logo which I designed. The previous logo, which I also designed, did not work well with the new layout, so I needed a new one. It's a small thing, but considering that I am a technology person and not a graphical designer, I think it turned out quite well.

This was a great project for me, not only did it improve the Norton Amateur Soccer Club's technology, but it also gave me the opportunity to learn more about Google Apps. From my experience setting all of this technology up for NASC, I have come to believe that many small organizations and businesses could greatly benefit from these services. There seems to be a great potential to reduce an organizations technology costs while actually improving the level of service.

SAP ABAP Training

This series of articles has been sitting as draft for a while, I guess I've been too busy to proofread it all. But, since I am on to another SAP training class, I thought that I should get these published.

I was in SAP training course BC400 this week to learn SAP ABAP. It was taught by Peter Walters, who seemed to have a thorough understanding of the subject mater. The course was a good introduction to the ABAP language and all of the various tools, or SAP transactions, that are required to write ABAP. In all I took about twenty pages of notes and I wanted to post the highlights here so that I will be able to refresh my memory once I actually need some of this knowledge. I am not an ABAP expert, so the information here could have some inaccuracies. If you need precise information I suggest visiting help.sap.com or sdn.sap.com.