MIUG Business Networking Conference 2008

Just saw a preview of Avikam Perry's roadmap announcement. Wow! I can't tell you what I saw, but I can tell you it will lead to unprecedented power for developers and huge benefits for business organizations running Magic applications. It is very important that you actually be present for MIUG as this presentation is not likely to be available in any other forum until what is being shown is actually released. You will want to prepare for this and the only way to do so is to be present at MIUG.

Magic Link Interview with Steve Blank

Steve Blank of S.G. Blank Consulting is no newcomer to eDeveloper™. His experience with, and advocacy of the platform, goes back more than 20 years to his introduction to Magic version 3.5 and it’s been his “tool of choice” ever since. But Steve is more than just a user; he’s an active contributor to the system’s capabilities. One example is the DDF Maker Wizard—a utility provided in eDeveloper V10—that lets developers enhance the eDeveloper studio by making their own utilities and wizards.

Magic Link: Tell us a little about your business.

Steve Blank: S.G. Blank Consulting only has one employee—me. I specialize in three different areas. First, I provide training for in-house developers on the latest aspects and features of Magic’s eDeveloper. Second, I speak at conferences and present seminars/classes on different aspects of eDeveloper. Third, I provide custom programming services to a handful of customers who, generally speaking, aren’t big enough to have their own in-house staffs, but who see the benefit of custom applications. It’s in this third area that I spend most of my time. I’ve been working with eDeveloper for about 20 years, since version 3.5, when it became my tool of choice, and I’ve been using it ever since.

ML: What types of training services are you called on to provide?

SB: Most of the companies for which I provide training are small to mid-size businesses with five or fewer developers. They are typically organizations that have developed their entire business system in Magic and, so, have a huge investment in it, and are looking for ways to improve performance or to solve other problems that have arisen as a result of their growth. So I’m usually not training people who are new to eDeveloper, but rather people in companies that have used the product for a long time and are looking for ways to make things better. The areas on which I tend to focus are multi-user concurrency, performance, database design, and data integrity.

ML: Do you typically provide training, then, for the same customers on a repeat basis?

SB: Yes. Often, I will get called in by a company that is experiencing a specific problem and, after helping them to resolve that problem, will then get called back to provide a wider scope of training. For example, a few years back, I received a call from a company in El Salvador that was experiencing increasingly serious locking and performance issues with their eDeveloper application. I went down and, after spending a couple days analyzing their application and database, showed them how to solve their problems and gave them some additional pointers on best practices. Each year since then, they’ve brought me back down for a week to train their development team on what’s new in eDeveloper, and to provide in-depth instruction on topics such as transaction processing and error recovery.

ML: You mentioned that you frequently speak at conferences. What types of things do you speak about?

SB: I tend to address many of the same topics that arise in my consulting and on which I often focus in my training, as well as to explore newer features in eDeveloper such as integrating ActiveX controls and COM objects. I really enjoy attending and presenting at conferences, for a couple of reasons: first, preparing for conferences gives me an excuse to experiment and create demo programs from which I learn something myself; and second, it’s a great way to network and to further my reputation in the business in a way that comes back to me. Plus, it’s just plain fun to meet and talk shop with people literally from all over the world.

ML: What are the kinds of issues that people have with eDeveloper that cause them to contact you?

SB: One of the strengths of eDeveloper is also one of its weaknesses: it’s really, really easy to write complex applications without a lot of formal training. Frankly, one can sit down and crank out some pretty amazing stuff without having any formal training in programming or database design because the tool abstracts the complexities to the point that the developer doesn’t really need to be aware of it. That’s one of its strengths because you can put applications together really quickly. But that also means that it’s very easy for bad habits to creep in. Take database design, for example. A Magic developer isn’t forced to be concerned about the table structures and such things that are underlying; one can just go in there and plunk things down. As a result, a lot of applications tend to have databases that aren’t at all normalized, which is OK when things are small with very few users. But as things grow and the database gets bigger and there are more concurrent users, problems can arise. That’s one example of when I might get called.

ML: What other types of issues do your clients have that you help with?

SB: A client might call up needing new reports or a change in functionality. One of the reasons I like eDeveloper so much is because it’s so much easier and faster to do not only new development, but also this kind of ongoing maintenance. One of the reasons to develop a custom application is so that one can constantly tweak it as one goes along, adding new features and functionality. With eDeveloper, that can happen a lot more quickly, which translates into lower cost (even when the customer is hiring someone like me to do it) than it can in something like Visual Basic. For example, my biggest customer in Massachusetts manufactures and distributes products for the optical industry. For lots of reasons, their software needs to evolve, practically constantly, and I make that happen. I develop a relationship with companies like that such that I’m really just an extension of their staff—almost an employee.

ML: There are some people who, like you, got started with Magic in the early days but then didn’t do much more with it. Why is that?

SB: First, Magic is a small company and suffers from a lack of brand awareness. Not enough people know Magic is out there, but it survives because of those of us who do know it are such zealous adopters that we just can’t see ourselves going anywhere else. More than that however, it often comes down to a political issue in favor of Microsoft. Whoever ever got fired for recommending Microsoft?

ML: Have you been able to observe companies like that?

SB: I knew one company that had developed its entire business system in eDeveloper and had run that way for 12 years, but then dropped it in favor of one of the major ERP vendors. They ended up shooting themselves in the foot. But once those decisions are made, people tend never to go back and revisit them or ask themselves if it turned out to be a good idea. They abandoned a significant investment in one system for another that ended up costing them many times more. But even though Magic has been around almost since the inception of the IBM PC and almost as long as Microsoft, people still ask, “Who’s Magic? Are they going to be around next year? Can we afford to take a chance with them, or should we go with Microsoft?” It’s a shame when a company turns its back on a significant legacy investment that was costing them much less money to maintain and, as a result, giving them a much better return on their investment.

ML: How can Magic go about showing those people what their prior investment in Magic could do for them now?

SB: I see a real opportunity now to speak to people who care about total cost of ownership. There are still people in this world who are willing to look at alternatives and to consider something different from the mainstream. Magic is doing a good job right now by releasing a product like eDeveloper Discovery, and by continuing to add new functionality.

ML: What advice do you have for Magic’s customers—old and new?

SB: Take a look at what Magic has done to improve the product over the years, such as addressing today’s increasing need to consume and serve web services, build and work with composite applications, and integrate with legacy applications and databases. If developers see how fast they can get the job done with eDeveloper and management sees how favorable the TCO is, they should agree that Magic is the answer.

A Little Magic History

I am constantly being asked about Magic's history, about the story of how the amazing technology that we know today evolved. Well, I can only tell you what I know.

Magic Software was founded in 1983 by Mashov Computers. Magic marketed application development tools and application deployment technology in the boom years of the personal computer craze (a boom that one could argue has not yet subsided). The programmers at Magic decided that if the computer was going to be perosnal and easy enough for everyone to use, that writing software was going to have to be a whole lot easier. While there had been some initial experimental attempts out of universities to create RAD -- rapid application development tools. None of them were all that useful because they tended to either be too complex or too restrictive and limited. So the developers at Magic set out to find a paradigm that would deliver full functionality and significantly reduce complexity.

SO there first and easiest decision was what not to do. They decided not to write a new computer programming "language." In fact they avoided traditional computer programming concepts and instead introduced a "table-driven" RAD tool. Today we know about concepts like pseudo-code, but they were really doing a lot of things we talk about in IT today: pseudo-code, services, mashups, etc. before anyone knew what to call them and really before they could be done as elegantly as Magic can do them today. SO they adopted an approach that required no compiling or linking. Because the pre-compiled sturctures could be employed and tested iteratively, the users of this new tool were able to prototype very quickly and start seeing results in minutes rather than weeks or months.

Te rest as they say is history, but let's remind ourselves of what that history includes: five years of victories at the Droege International development competiton, including the final year in which Magic's customers swept every prize at the contest, forcing the organizers to give up. Why continue holding programming competitions if the results are a given, Magic is the best and fastest tool. Ah, if only the market dynamics today were that simple.

Magic has had to try to preserve it ssimple table driven concept despite massive torrents of change in the underlying architecture of the computer. Not only has there been a major shift from text-based DOS environments to newer and arguably improved GUI operating systems, I don't know why I bother to use the plural, we all know I'm talking about Windows. But there was also a major shift from standalone PCs, to networked PCs on a LAN to PCs connected over the Internet -- the "cloud" as we sometimes like to call it. Magic also got a little ambitious too. The world of DOS and Windows in the 1990s was still not where most of the Fortune 2000 companies transacted their IT business. So Magic decided to expand the concept to include VMS, Unix, OS/400 and eventually Linux. The original dos version used Btrieve, these other environments used other databases and ISAM file systems. So the Magic development tool had to be given new "gateways" to deal with these new databases. Magic was able to sell these gateways as seperate products to their customers. Of course that transition to these other environments also meant a difference in architecture for the applications. The original desktop application approach was not a broad enough paradigm for these new distributed architecturess, so Magic's tool added client-server and Internet deployment methodologies. Known today as eDeveloper V10, Magic's development tools can deliver applications over the Internet in a browser-client mode or an HTML merge mode that is similar to PHP in the way it tags the HTML and merges in the results of its processing.

I'll probably have a lot more to say about this topic in the future, but I'd better get back to the topic of migration before anyone complains that I forgot to deliver my promised final chapter on moving your application to eDeveloper V10.

Converting to eDeveloper V10 (the Migration Story continues)

OK, you're probably thinking: I was a convert to the Magic way of developing a long time ago: why do I need to convert? But I'm talking about a more routine kind of conversion here, the conversion utility that automates the move from eDeveloper v9.4 to eDeveloper V10.
Needless to say, (oh don't worry, I know I say needless things all the time anyway), the Conversion Utility feature does not exist in the Discovery version. The discovery version is designed for beginners and beginners only. If you already have a big application, you're not a beginner.

Getting to Know the Conversion Utility

If you've gotten very far into this, you probably already know that eDeveloper V10 provides an Application Conversion utility for converting your eDeveloper V9 application into an eDeveloper V10 project. Please remember that this utility is designed only for full applications written in eDeveloper V9.4sp7 and onwards.So, if you have to do something to get your application to eDeveloper v9.4 sp7 (or later) first, then do that before attempting the conversion utility. Be warned.
As the documentation ably illustrates, you can launch the Application Conversion Utility from the Windows Start menu > (All) Programs > eDeveloper V10.1 > Migration > V9 Migration UI.
After you launch the application conversion utility, aka V9 Migration UI, you will see its Welcome screen. When you click the Next button, the Version 9.4 Applications Screen opens, and this is where the fun begins (OK, not really fun but I am trying to make this different from the documentation in tone and style, is it working?).

Version 9.4 Applications Screen

So you may be wondering, why do I have to add everything one by one? Well, the answer is simply that you may not feel the need to convert all your applications and components, so just choose the ones you truly want ti the new world of eDeveloper V10. (After all, why convert that cool BetaMax Catalog application? So when you convert an application, each application and its component must be added to the Version 9.4 Applications screen by clicking the Add button. If your application has references to a component that has already been converted, you should still add that component to the list at this point. That's right, do it again, you are telling the convert utility to make that component available to this application in the new world of eDeveloper V10. So just do it.
Each time you click the Add button of course, the Conversion Details screen opens and you have some disambiguation to do.

So This is How You Use the Conversion Details Screen

In addition to the how, I'll try to answer the why, without simply saying "because that's the way it is." Basically, the reason for the conversion details screen is for you to communicate your intent. Do you want to convert all of the application or just part of it? Do you want to convert a new component, or has it already been converted and you just want to reference it? These are the kinds of questions you are answering in this screen. So you simply select whether you are converting an application, part of an application, a component, or keeping the reference for a previously-converted component.
For each export file there are four possibilities (the order entered is not important):
Convert an application - The utility converts the entire application to V10 (but not its components, you are adding them separately, remember?).
Convert part of an application – Now it gets a little particular here, because this option cannot be combined with other conversion types in the same process. That doesn'tmean the very next add operation cannot use one of the other selections, it just means that in a single add operation, you are either choosing part of an application, or some combination of the other three options: convert an application, convert a component or keep a component reference. So, all the other options can be added one after another and all of them will be converted in the same conversion run or process. That is why, this option can only be selected if you have not yet selected one of the other options since starting this session of the utility.
You can continue with additional V9 export files using the Add button.

Convert a component - The utility converts the application to V10, and finds all of the references to the MCF or MFF in all of the Component repositories in the conversion list (the first screen). Then, the utility changes their references to the newly created ECF.
Keep reference for previously converted component - The utility points to the references of this component to the previously converted cabinet file. By doing this, we do not have to convert the same application twice. This is useful if we have a component with models, which is used in a number of different applications.
Depending on which option you select, you then fill in the application details and/or project details.
When you convert an application and its components, the utility will take the name of the component (entered in the Component File Name field) and change any reference to that file name in the Composite Resource Repository with the V10 cabinet file (in the V10 Project Name field).
The Cabinet file location field governs where the conversion process creates the cabinet file.

When you click the Next button, the General Settings screen opens.

Salute the General Settings Screen

The General Settings screen has the following settings:
V9.4 Magic.ini File – The Magic.ini file used in the V9.4 application.
Log file directory – A path for the log file directory.
Log Level – This setting has the following options:
• Full – Displays the full log.
• Partial – Displays errors and changes of behavior only.
Convert empty eDeveloper handlers – This property governs whether the Record Prefix, Record Suffix, Task Prefix, and Task Suffix will be converted if they are empty. In previous versions, these built-in handlers were created automatically even if they were empty. These empty handlers are irrelevant in V10. If you select this check box, the empty handlers will be included in the converted application. If this check box is not selected, the empty handlers will be removed.
"SpecialModalToolWindow" – In previous versions, the caption of Modal windows was narrow while in V10 it is a full sized caption. Select this check box if you want the Modal window height to be increased in order to fit the contents.

But as we shall see next, you can also go to directly to the conversion executable file.

Taking Command with the Command Line Conversion

eDeveloper V10 does not support the eDeveloper V9 export file structure, however it does provide a command line conversion utility called v9converter.exe that converts eDeveloper V9.4sp7 export files to a valid V10 application.
The v9converter.exe file is located in the eDeveloper V10 installation directory.
When the export file is executed with no parameters or when you enter /?,the Conversion utility help text will appear on the screen.
When you run the utility, the conversion results are displayed on the screen.
If the conversion process fails, you should verify that the command line syntax is valid and that the application is in a valid version 9 export file format. The utility will create the .edp file in the specified project directory and the project source files in the Source subdirectory.
The conversion log file will be created according to the -LOG parameter. If this parameter is not set, the log file will be created by its default name.

So remember, if you need to migrate only a partial application, you need to use the Command Line Conversion utility.

In the final entry on the migration process to eDeveloper V10, we will take a look at what the conversion utility parameters do, try to explain how application behaviors can be changed in the conversion process, and finally, recap some of the troubleshooting issues related to your conversion. Let's hope this whole approach demystifies a lot of this for those of you who have been wondering, what is really involved? As you can see, it takes about as long to explain it all in detail as it does to perform the actual migration. So much for the blah, blah, blah.

Crossing the Border to eDeveloper V10

Part One: Preparing Your Application

I don't know why exactly, but somebody coined the term "migration" to describe the steps involved in bringing an existing application from an older version of its development/deployment environment to a newer version. When I think of "migration" I picture a flock of birds flying south for the winter or a long line of cars crossing the border at Tijuana. Fortunately, migrating an eDeveloper v9 application to eDeveloper V10 is considerably less exhausting than either of those images might imply. Keep in mind, that eDeveloper applications cannot be converted to eDeveloper Discovery, since the purpose of Discovery is to introduce new developers to the Magic paradigm. Migration is therefore available only to eDeveloper Express and eDeveloper Enterprise.

eDeveloper V10 offers an entirely new approach to creating, storing and handling your eDeveloper application development projects. One of the things that you will notice is that eDeveloper V10 does not support the previous version's export file structure. But not to worry, a conversion utility is provided.

So crossing the border to eDeveloper V10 involves three easy steps: prepare your application for export, export the application, and run the conversion utility. It's just that simple, but let's look into each step a little more deeply and then discuss the three utilities available once your application has been migrated.

Preparing Your Application for Export

Prior to exporting your application, you should modify your application by replacing any unsupported features that you may have used with new approaches. In this fashion, you will ensure that no program information gets lost during the conversion process.

Unsupported Features
A number of older features have been removed: DVAL3, ESTR, FLOW3, Pref, ISTR, IVAL, LSTR, WebRef, EVAL, RVAL, RSTR, LVAL, STR3, TSTR3, TVAL3, VAL3, and the Euro functions, EuroCnv, EuroDel, EuroGet, EuroSet, EuroUdp. All of these were deemed unneeded or superfluous for one reason or another. So make sure to remove them from your application if you happened to use them in the past. Chances are you did not use these functions anyway, but you should check. And remember, while you do not have to do anything to prepare for features that have been renamed, about ten functions have new names in eDeveloper V10. So the conversion utility will change these automatically, such as changing ASC to ASCIIVAL, etc.

Changing Memo Attributes
You also need to know that any variable with a Memo attribute in your v9 application is going to be changed automatically to an Alpha attribute. Database fields that had Memo attributes will be converted to Alpha attributes with Memo storage. And of course, the VarAttr function will no longer return 'M' for Memo as this is no longer an eDeveloper attribute. But once again, don't worry, the conversion process will not automatically change expressions with the VarAttr function. Nevertheless, you should probably search for the string VarAttr to see where it is equated with 'M'. You will want to adjust your program in these rare situations, because VarAttr will no longer return the value 'M'.

A Fond Farewell to Web Online
"Web Online, we're glad we knew thee, but alas it is time to departeth." Yes, Web Online is that old and it is time to abandon this approach if, tsk, tsk, you hadn't already done so. To be clear: Web Online is not supported in eDeveloper V10. Older forms with the Web Online Response interface type are not supported in eDeveloper V10. The conversion utility simply removes these types of forms from your application. So any existing Form Output operation pointing to these forms will not point to a form in the converted project. Magic recommends that you remove any form of this type before exporting your application.

And HTML Forms Must Get the Boot As Well
As a result of improvements and greater flexibility in the new Merge capabilities, and to prepare the way for even greater enhancements in the future, eDeveloper V10 will not support forms with the HTML interface type. Once again, the conversion utility simply removes these types of forms from your application, and any Form Output operation pointing to these forms will not point to a form in the converted project. So Magic recommends that you remove any form of this type before exporting your application.

So this change implies a number of changes from the way things used to work: 1) The HTML property has been removed from the Style section of the property sheet of variables, columns and models. 2) The HTML class has been removed from the Model repository. 3) The Internet Development File Root property has been removed from the Project properties. 4)The Internet APG is not supported. 5) The HTML Merge Interface Type is now named Merge. The Conversion utility will convert the HTML Merge values to Merge.

As you get deeper into eDeveloper V10, you will see this as an enhancement with a more flexible and useful approach to Merge.

Goodbye to the Old Browse Function
The browse function was rather single purpose and it is simply more flexible to replace this with an Invoke OS Command operation that gives you the flexibility to do more than just Browse. So, as a result, the Browse operation is not supported in eDeveloper V10. Magic recommends that you remove any Browse operation before exporting your application. Keep in mind, however, that the Conversion utility will replace the operation with an Invoke OS Command operation.

Other Unsupported and Removed Properties that Will Not Convert

Environment properties
The Multi User Access setting has been removed from the Environment dialog box.

Euro-Related properties
A number of older Euro Support features have been removed because they are simply not needed any longer. First of all, the European Currency Conversion File environment setting was removed from the External tab of the Environment dialog box. The EuroFile environment setting was also removed from the MAGIC_ENV section of the Magic.ini file. Needless to say, the Base Currency and European Currency Conversion File application properties were removed too. And as mentioned above, several Euro functions are no longer supported.

Java Browser Client
The browser client of old was a Java applet. No more. To reflect changes in the most commonly supported client applet technologies available for Internet Explorer, the Java option has been removed from the Browser client technology setting in the Server tab of the Environment dialog box.

Java Component Generator (JCG)
We used to have a separate generator called the Java Component Generator. This concept has been significantly expanded upon to allow composite objects of all types to be generated, including your own ability to write composite generators. All of these are now found in the new and exciting Composite Resource Repository in eDeveloper V10.

Out with the Old XML Component Generator (XCG)
Significant improvements in XML handling have been added in eDeveloper V10. You can learn about these in greater detail in one of the recent XML Webinars in the Magic Software webinar archives. Anyway, the old XML Component Generator has been removed to make way for these enhancements.

Minor Change to Application Properties
The rather obscure "Internet Development File Root" property was removed from the Application Properties dialog box.

DBMS
Three columns have been removed from the DBMS repository:

2 Phase

Excl. Trans.

ID

In corresponding fashion, some Magic.ini settings were removed from the MAGIC_DBMS section: OnePhaseCommit, TwoPhaseCommit, NotTransLockExcl and TransLockExcl.

Databases
Several columns and properties have also been removed from the Database repository. The Magic Server column was removed from the Database repository. The Common Data Dictionary property was removed from the Options tab of the Database Properties dialog box. And the XA Transactions property was removed from the SQL tab of the Database Properties dialog box.

Internet APG is out the door
Out the door forever, I should add. The Internet APG for a table or task is no longer supported. The Internet tab was removed from the APG dialog box.

Export Document
The Export Document option was removed from the Operation list in the Export/Import dialog box.

Studio Rights
Finally, (well, with blogs, nothing is ever final) the Studio rights have been removed.

Colors and Fonts
This next consideration is optional. Some of you may prefer the new eDeveloper V10 color and font settings. Nevertheless, if you want to maintain your application's colors and fonts, you should set the Application color and font definition files and the Internal color and font definition files of the converted project to be directed to the color and font definition files of version 9. This is a onetime setting change for each application and project.

Security File
You will likely want to use your security file (such as usr_std.eng) from the previous version, but you do not have to. If you decide to convert your existing security file, run the usrupd.exe utility from the command line. The syntax is:

usrupd *input* *output*

*input* is the name of your current file name and *output* is the name that you want given to the file that is created by the usrupd.exe utility. And you should keep in mind, very importantly that in eDeveloper V10 you can only assign runtime rights.

Terminology has changed too
I won't get into terminology changes here because I don't think they are relevant to the migration itself. But you should definitely familiarize yourself with the new terminology in eDeveloper V10 as compared to the prior version.

Next time:

In my next blog entry, we'll discuss the export and conversion steps. So stay tuned.

Magic eDeveloper V10 and ROI for Start-Up Businesses

The economy has been showing signs of weakness. Despite this, thousands of entrepreneurs will be launching new businesses, even in the midst of a new economy. How does that affect software development? Building the software systems for these new businesses is a critical process and one that must complete in the least possible amount of time. During slow economic times Return on Investment is on the mind of every entrepreneur who has to sign off on a development budget to get the new business systems in place that will deliver their unique competitive advantage. So in today’s business climate, the emphasis is on rapid return on investment. The break-even point needs to be achieved at the earliest possible moment. Every cost has to be analyzed against the expected returns to arrive at estimated break even dates. So here’s my claim: “You can achieve ROI in your application development process faster and with greater assurance when using eDeveloper V10.”

Application development tends to occur in phases. For our purposes, let’s consider these four phases: Design, Build, Test and Deploy. In the harried environment of a new startup business, you need to have all four of these occurring almost simultaneously, but traditional computer programming tools do not allow this. All four of these phases require an investment of time, but if you can execute some of the phases in parallel, then you can get to the final destination faster. So testing isn’t something that happens at the end of a software process, it is an iterative process that occurs throughout the project. For this reason, it may be more useful to think of Design, Build, Test, Maintain not as phases, but rather as layers of the development task. The design layer tends to be front-loaded in the project, but some design occurs while maintaining the program. The test layer tends to be back-loaded towards the end of a project, but using sound iterative design principles, testing definitely occurs throughout the life of the project.Time is money is perhaps a cliché but critical when discussing the ROI of business software development projects for new businesses.

Application Development ROI calculations must put the emphasis on the investment that goes into dollars paid to the developers on the project; i.e. how many developers will it take and for how long? The sooner the project comes to a successful end, the faster the ROI for the project, and the sooner the new business can deploy their new systems and reap the benefits.

The time saved - hence the ROI - using Magic eDeveloper V10 is significant: typically from 4 to 6 times faster than that of other development technologies.
The table below is based on extensive market research and compares each of the four phases (layers) of the application development lifecycle for 3GLs (Third Generation Languages), 4GLs (Fourth Generation Languages) and Magic eDeveloper. If X, Y, Z, and W represent the time spent on an average 3GL application for each of the application development phases, research shows that generally 4GLs cut the time in half. With Magic eDeveloper even better time- savings are achieved. The productivity gains shown below are conservative calculations by Magic Software based on interviews with eDeveloper programmers, many of whom are quoted later.



In order to achieve rapid ROI, each phase of the lifecycle must not only be completed quickly, but must also have the highest reliability to ensure the fastest payback for the investment being made.
In going through the analysis of each of the application development lifecycle phases in future blog entries, I will detail additional aspects of Magic eDeveloper that result in further ROI increases.

Magic eDeveloper’s progressive development paradigm allows prototype applications to be quickly and easily created. The eDeveloper paradigm is often used to convince venture capitalists and other investors that achievement of a new start-up businesses goals for new business systems is in fact achievable. Without eDeveloper, some businesses might not even “get off the ground.” In addition, the ability to support applications over time despite changing business models, platforms, and standards is inherent in the Magic eDeveloper development technology.

Rapid ROI remains a key critical measure for every new business and is often the difference between success and failure. I’ll comment more on the savings possible during each phase of the application development cycle in later posts.

Top Ten Ways To Gain Approval of Your eDeveloper Upgrade

Getting the boss's approval to upgrade important software can be a challenge, particularly when budgets are tight. Here are a few tips on how to get approval to upgrade eDeveloper V10:

PREPARE. Go in armed with all the necessary materials to make a good case for your upgrade. Download the “Ten Reasons” brochure and visit the series of blog entries on reasons to upgrade in Glenn Johnson’s eDeveloper V10 blog.

LEARN. Attend the Magic University course “Migration to eDeveloper V10” so that you can speak with authority on the capabilities of eDeveloper V10. Download the FREE EVALUATION SOFTWARE and consult the "What's New in eDeveloper V10" and other documentation.

RELATE. Show how specific problems or issues you've recently encountered can be overcome by one of the improvements in eDeveloper V10. Ask for a Magic representative to setup a live web presentation on your upgrade to eDeveloper V10. Invite your opeers and your boss to participate in this information gathering session.

SHARE. Point others in your organization towards the new learning resources in eDeveloper V10: the “Mastering eDeveloper” book and the 22 online demonstrations.

SAVE. Point out the ROI benefits of migrating to eDeveloper now, before you release a new version of your software based on your current version. Cost savings, productivity enhancements, application improvements, user interface benefits, and much more, are all available immediately, but only if you make the leap to eDeveloper V10. A delayed start to active development using eDeveloper V10 equates to a very real loss of benefits to your company.

TEAM. Review the benefits of eDeveloper V10 with other members of your development team. Gain an understanding of how the improvements can enhance efforts across your development team.

CONSULT. Magic Professional Services can help to provide you with a migration readiness assessment. This formal consulting process will help you to plan for all aspects of your migration to eDeveloper V10.

LAUNCH. Ask for a commitment on a specific launch date for your team’s use of eDeveloper. Come in armed with a launch plan.

MEET. Set a specific meeting in which you can present your upgrade request to senior management. Make it clear to everyone that this is an important and needed decision.

DECIDE. Give a deadline to make a decision. Present the information and ask for an answer within a specified time frame. Reiterate that procrastination has real expenses and costs associated with it as well as lost business opportunities.

Developing RFID Applications with eDeveloper V10

Last month, I attended the Active RFID Summit held in Dallas, Texas. In addition to enjoying a chance to sample some excellent Tex-Mex dishes, I really appreciated the chance to compare notes with colleagues on the state of the art application of RFID, especially active RFID. Regardless of whether you are developing proprietary applications, vertical applications for a specific industry or horizontal applications that serve cross-industry needs, RFID is putting a strain on IT resources. Active RFID represents a major paradigm shift in data acquisition and generation creating an onslaught of data that current applications are generally not prepared to handle.

Stephen Moody, an RFID Program Coordinator for the Combat Feeding Program of the US Army's Natick Soldier Research Development, presented a fascinating case study entitled: "DoD Active RFID Applications for Supply Chain Security and Shelf Life Management." It is easy to underestimate RFID as something akin to a glorified barcode or a "traveling database". But many active RFID tags are far more sophisticated in that they incorporate environmental sensors. The US Army sends tons of rations to the troops in Iraq and elsewhere. These shipments are made in ships holding thousands of standardized shipping containers. How can the US Army be sure the shipments have not been tampered with or exposed to unacceptable environmental conditions? The answer is active RFID tags with sophisticated sensors for a number of environmental events: temperature, radiation, light, chemical agents, biological agents, shock, door sensors, etc. If somebody is doing something to a shipment of food, or if it just gets too hot for too long, the US Army knows when it happened and where it happened. This is simply one of scores of applications for active RFID in an organization like the US Army. But what does one do with all that data? According to Moody, "the greatest barrier to the successful implementation and adoption of RFID is integration to legacy systems."

One of the other challenges for RFID is the current lack of standards. In some ways this is unavoidable: RFID is not a specific product, technology or protocol. RFID is a family of technologies that incorporate radio frequency and are used to identify "stuff." As Sue Hutchinson, the Director of Industry Adoption for EPCglobal US put it, RFID provides the answer to the question "where's my stuff?" But the type of RFID may involve passive RFID, where the tag has no power source and is a write-once technology, to active RFID, including ultra wide-band (UWB), all the way to GPS and beyond. With such a diversity of technologies, standards become even more important. Lacking these standards, however, flexible development and integration tools become even more important.

Consider the food safety example above, somewhere in an ERP system the information resides for the supplier name, items ordered, supply date, carrier and so forth. Does this information get integrated to the data on the RFID tag? What happens if food from one supplier is more prone to spoilage or to lose palatability under prolonged high temperatures? How can the US Army, or any organization for that matter, take full advantage of RFID applications if key information sits locked in a silo such as an ERP or supply chain system?

Information integration is the key. But how does one best handle RFID integration with an ERP or other existing application? To answer that, we first need to consider the RFID system being used. RFID systems involve tags (some with built in sensors), programmers, readers, networks and so on. But most do not include middleware. And the hooks provided are inconsistent. Text files, XML, .NET objects, java objects and Web Services are provided inconsistently. For an organization to be prepared to integrate the data from a reader, they can benefit from a middleware solution like iBOLT that provides the ability to consume any of these data types and orchestrate them within an overall business process. Or they can create interfaces from directly within an eDeveloper application. Even when dedicated applications are written to take advantage of RFID data, middleware and business process management software is still needed to facilitate integration to legacy systems. Ideally, these middleware systems are service-oriented including event driven capabilities, discoverable web services and more.

Unfortunately, too many RFID early adopters are resorting to hefty J2EE or.Net based programming projects rather than utilizing a development tool like eDeveloper V10 or a simplified visually-oriented business process design tools like iBOLT. As the world begins to find more and more uses for RFID, it will be useful for serious organizations to incorporate eDeveloper and iBOLT for integration to RFID data, whether it comes in raw text or XML format or is served up by a Web Service or programming object like .NET or XML.

With RFID, the emergence of integration file standards is far from certain. The Auto ID Center has proposed an XML format known as PML as a standard. You can read about it on the XML CoverPages hosted by OASIS. But the adoption of the standard is far from ubiquitous, especially in the Active RFID world which tends to look at organizations like EPCglobal with at least some degree of suspicion.

The good news for eDeveloper programmers is that since PML is just a flavor of XML, you can access RFID data with standard eDeveloper XML tools. To see what you’re avoiding, take a look at the PM example below. For more information on RFID and iBOLT, you can access Magic Software’s RFID related webinars.

Using PML in eDeveloper V10
eDeveloper V10 includes a new capability called XML Integration. This approach makes PML’s use within eDeveloper much easier. In fact, you can now develop applications using eDeveloper with no database at all and simply use XML files, including PML for RFID and other Auto ID related applications.

When using a PML data source containing RFID data, you can create eDeveloper tasks (batch and online) that use the PML files as their view (main files and linked files). You can define an PML data source in the Data repository (remember PML is XML) and define a task to manipulate and handle the PML. You can check that the XML task is compatible with the XML schema by using the XMLValidate and XMLValidationError functions. Namespaces are automatically handled by eDeveloper.

There are two XML development methodologies to choose from. You can develop applications using XML in the data repository or you can develop using XML with BLOBs. If you use both methods, then the BLOB takes precedence.

With eDeveloper V10, a task that uses XML (such as PML) will first open the entire XML file (if it is not already open) and then populate the tables. It then executes the defined task, whether that be query, insert, update or delete. Finally, when closing the task, if the data has changed, then eDeveloper V10 writes the XML BLOB or file back over the original XML source.

eDeveloper V10's XML Integration feature provides two functions that allow you to verify that the XML is compatible with the XML schema.

The functions are XMLValidate, which validates an XML document against its schema; and XMLValidationError, a function that returns the errors of the last XMLValidate. This will help you to determine whether your PML file is valid based on the PML schema, which of course is found in the .xsd file.

With eDeveloper V10, you can use the Get Definition function to discover the properties of a PML file that contains RFID data and map them to an eDeveloper table. Like all XML files, PML files are described by .xsd metadata that contains the XML schema definition. During a Get Definition, if an element’s/attribute’s type is defined using a SimpleType or as a reference to a Global element, it will be converted to the appropriate Primitive xsd data type from which it is derived.

Primitive xsd data types are mapped to corresponding eDeveloper attributes. Once this occurs, the field attributes can be changed without restriction. A default picture (most of the time you can think of this as length) will be assigned (as specified in the table). When the type is based on a SimpleType, which defines length, the picture will be updated with the length specified for the SimpleType.



What About Other RFID Data Integration Types

To be sure, RFID vendors are not uniform or universal in their support of RFID data via PML or XML. Fortunately, eDeveloper has built in functions for the other common methodologies as well. Some vendors supply RFID Web Services, which means you can use the eDeveloper V10 Web Services wizard. That’s even easier than dealing directly with PML or other forms of XML.

Occasionally, programming objects such as java objects or COM objects are provided, in which case eDeveloper can call and pass information to these objects. Keep in mind that Active RFID enables two-way data communication and write-many read-many (WMRM) storage with an RFID tag, whereas, generally speaking passive RFID is a write-once read many (WORM) technology. That means your eDeveloper applications need Active RFID if they are going to do any of the more sophisticated RFID applications.

Ways to Apply RFID Technology in eDeveloper Applications
Going back to Sue Hutchinson’s comment, RFID helps to answer the question: “where’s my stuff?” One way to determine this is to sense the immediate presence of an FID tag next to a reader. This approach works well, with say, tagged parts that are passing along an assembly line. The parts are always within range of the reader. Another example of good stationary reader approaches might be warehouse doors. Some work has even been done to create “smart shelves” that sense the RFID tag of products as they are pulled on or off the shelf. For these close proximity applications, passive RFID may be satisfactory.
But the real world does not always have these convenient thresholds.

One of the technologies developing around RFID are Real-Time Locating Systems (RLTS). These systems measure the wave properties of an RFID signal to determine the location of an RFID tag. The readers are generally placed in a grid and then tuned to a room or outdoor location. Since waves travel inconsistently through and around walls, etc., bandwidth is a consideration with RLTS. In cramped spaces, UWB is often preferred and it may offer energy saving advantages as well. Battery life in an RFID tag is another important consideration. Beacons that emit constant signals use more energy and have shorter battery life than systems that simply “chirp” at an established interval.

Software algorithms that calculate the location of a tag by comparing signal strengths on a grid of sensors are quite sophisticated. But they aren’t always accurate. Practical field applications show that errant readings are fairly common. When possible, a location should be calculated based on the average of several readings and not just a single reading. This approach leads to a great deal of accuracy.

RLTS can be used in applications such as worker safety systems. Companies like BP use active RFID in their employee badges so that if disaster strikes at a refinery or other hazardous work location, systems can be used to pinpoint the locations of workers and visitors. Needless to say, the RFID readers in these systems have to be “hardened” to withstand violent environmental conditions such as fire and explosion.

Another common use of RLTS is in asset management software systems. These often take on specialized use in various industries. Nurses need to know which room an IV cart or other mobile medical equipment was left in. Newspapers need to know where the paper stock rolls are in their automated factory. Truckyard operators need to know which spot particular trailers are located in, etc.

Glorified barcodes? Perhaps. But when was the last time a barcode could tell you whether the product it tagged has been kept at safe temperatures or automatically report its location? Sure we know we scanned it into inventory six months ago, but don’t ask us to actually find it in the store or warehouse.