Upgrades Make Cents and Sense Says IDC

Upgrading your Magic Application Platform to the latest version of the Magic xpa Application Platform makes both cents and sense according to IDC. As IDC analysts Jean Bozman and Randy Perry report in their White Paper on upgrade costs, “a buy-and-hold strategy can actually add costs to the datacenter, for a number of reasons, as systems age in place.” Bozman and Perry point out that as applications age, their maintenance and support fees typically rise; that aging applications cost more due to poorer performance over time including increasing downtime; and that the aging of the entire software stack  (operating systems, databases, application platforms, applications, etc.) after about five years incurs costs related to lagging behind currently available technology.

Forrester Research suggests that businesses considering software upgrades take into account what they call Total Economic Impact (TEI). TEI incorporates cost-benefit estimates in much the same manner as Return-on-Investment (ROI) and Total-Cost-of-Ownership (TCO) analysis do, but it adds two additional factors: risk and flexibility. This pushes an organization to look beyond known costs to an evaluation of future risks that incur by failing to upgrade. It also strives to put an economic estimate on the benefit of having more choice in the future for needs and opportunities that cannot even be accurately foreseen today.

At Magic, we use the tagline “Outperform the Future.” A big component of this is being prepared for the unknowns that the future most certainly will bring. That’s why we can put an economic value on risk and flexibility. The details may not be precisely known today. But the certainty of future value to an organization of being prepared for those future unknowns is huge and not to be overlooked. For this reason, many organizations simply view upgrades to their Magic xpa Application Platform as a key to future success and benefits to the organization.

Rather than viewing software version upgrades, updates and enhancements as a cost center, they see it as an opportunity to continue providing vital business solutions in an agile manner.

A great illustration of how Magic technology de-risks the future and provides more flexibility is found in the example of enterprise mobility – the challenge of doing business on the go with smartphones and tablets. Magic xpa provides all kinds of flexibility with the ability to extend business processes to Android, iOS and other devices while at the same time dramatically reducing risk (not to mention cost) by allowing you to start development by leveraging an application platform that already contains your existing pool of business logic.

Magic xpa also allows you to seamlessly transition to .NET, deliver secure business applications anywhere over the Internet with Rich Internet Applications (RIA), and create new versions of your applications for the latest releases of databases and operating systems used for desktop and web environments. If you are one of the minority who has not yet transitioned your users to Magic xpa IApplication Platform 2.x, what are you waiting for? Now is the time to Outperform the Future.

Developer’s Guide to Mobile Order Tracking Apps

Developing Mobile Order Tracking apps for deployment across multiple mobile platforms? When designing your app it is important to keep in mind the differences between order tracking and simple shipment tracking.

With a shipment tracking app we start with a tracking number and have a simple question in mind: where’s my package? These apps are very easy to build because you can simply pass the tracking number to the shipping company web service as a request and receive back shipment information from the shipping company web service. For a company like FedEx that ships 9 billion packages per day, there’s a lot of big data integration taking place behind the scenes of that simple Web Service request, but as the mobile app developer, you don’t need to worry about that.

As the developer of an order tracking app, you suddenly have taken on a much more complex task. Order tracking differs from shipment tracking in the following ways:

Multiple Shippers.  In many businesses, an order may be shipped by a variety of different carriers. Not only FedEx, UPS, DHL, USPS and other well known small package delivery companies, each of which offers Web Services for package delivery and tracking information, but also other carriers such as CEVA Logistics, DAMCO, and literally thousands of trucking, common carriers, sea cargo, air cargo, rail, freight and freight forwarding companies.

Multiple Shipment Methods. In addition to tracking multiple shippers, an order being tracked may have a variety of different shipment methods associated to it. In addition to common designations such as same day, next day, 2-day air, etc. you may also have alternate methods such as will call, in-store pickup, download, digital delivery, license keys and hold for further instructions.

Order Information. In a simple shipment tracking app, all you have is the tracking number and perhaps weight and dimensional information. You don’t necessarily have any information about the order itself: quantity, item number, name, description, price, etc. An order tracking app will typically have all of this information available as well. From an app design standpoint this becomes problematic because you obviously don’t have the screen real estate for all of this information. So even though your app spans a broader range of related information regarding the order information, you’ll want that information on a separate tab.

Multiple Orders and Order Status. Since you may be tracking multiple orders, you’ll want an easy way to find and display orders, usually by order number, date, or keyword search. The home screen for an order tracking app may indeed be a list of order numbers with most recent open orders first and oldest delivered orders last. Color or bold text on the order number can be used to clearly identify open orders versus closed orders. Partial order logic will need to be considered as well as this is a common scenario in many businesses.

Payment Information. Another tab to track payments related to orders may be desirable as well. As payment methods will vary, so will payment status and the way that payments are applied.  In some businesses, payment methods may fail after an order has placed. Such as a delayed credit card rejection. In these scenarios, you may want to highlight these orders that need payment attention on the home screen and also provide mechanism to the customer and/or salesperson to cancel orders in accordance with your business rules. When customers have terms and make payments after the fact, credit status may affect the status of an order. For example, an order may be accepted but not processed until a payment is made to return the credit status to normal. This is common in many industries and may need to be accommodated in your app as a business rule.

Salesperson’s Tools. Salespeople and sales management may also need mobile order tracking apps, since they deal with multiple customers, they may need to have an ability to see orders in a variety of ways: by date, by product or product type, by customer, by salesperson, etc. From the home screen, the salesperson or sales manager should be able to apply filters so that they see only such orders. User rights for salespeople, sales managers, warehouse and logistics personnel and customers will all vary. Keep role based rights and security in mind when creating your app.

Summary. In summary, an order tracking app will begin with a home screen that allows the user, based on rights, to see relevant orders. Drilling down on an order will normally display the shipment status on the tracking information tab along with the desired shipment tracking details. If information on the order details is desired, clicking on the order number in a shipment status tab will open the order tab containing order details, clicking on the order amount can display the payment/credit status information. Here again, color coding the payment amount green, red, etc. can help identify payment status at a glance without the need to click on the amount to open the tab. Depending on your business rules and user desires, a mobile order tracking app can be developed with any number of options. Fortunately, the Magic xpa Application Platform makes the creation of these apps straightforward and allows you to deploy them across multiplemobile OS including iOS, BlackBerry and Android. Then the Magic xpi IntegrationPlatform can handle back-end enterprise integration to shippers’ Web Services and your own ERP system for up-to-date information.

Mobile Saturday

In this demo, Magic demonstrates how you can easily develop applications that deploy natively on all mobile devices. The sample app is sort of silly, an "asset management" app for families in which family members set meetings like "portfolio management review." That made me laugh, but then the video gets into the Magic xpa Studio and shows how-to add form controls, bind variables, set data sources for drop-down lists, and so on. Not bad!

One nice aspect is that the new application does not have to be redistributed to users. The next time they run the app, it is simply the new and enhanced version that executes. In this sense, RIA apps, are a lot like SaaS or web-based apps. 

With the Magic xpa Application Platform, a single development effort can create apps that run on multiple devices such as the Android example in the demo. 

Be sure to register for the Magic Software Users Conference 2013. 

Magic Software Users Conference 2013

Magic Software Users Conference 2013

June 3-5, 2013

Encore at the Wynn Las Vegas
Las Vegas, Nevada, USA

You've probably heard by now, but after a three year hiatus from Las Vegas, the Magic Software Users Conference is returning to Las Vegas, Nevada for 2013.  

As many of you know, the Magic Software Users Conference combines top-level educational experiences in Magic technology and not-to-be-missed business networking opportunities with the excitement and glamour of Las Vegas. We are placing a renewed emphasis on hands-on educational experiences so that you can gain insights from Magic R&D, tech support, professional services consultants and fellow-users on the latest capabilities as well as time-tested approaches in the application of the Magic xpa Application Platform and the Magic xpi Integration Platform. 

Encore at the Wynn will provide an exquisite and surprisingly affordable environment for the educational program. Despite our luxury accomodations, the cost of the program remains unchanged from prior years and we have a great rate of $149 per night. Because this is the only "conference" in North America where you the developers put on education sessions alongside Magic R&D, this is a not-to-be-missed opportunity.

Attention Developers: Please submit your session proposals for the Magic Software Users Conference 2013 by February 1, 2013 to gjohnson@magicsoftware.com

Session proposals should include your name, company name, proposed session title, description and a brief statement of your experience with Magic technology and the proposed subject matter. Please feel free to propose a special format such as a panel session, tutorial, group discussion, etc.

We are seeking speaking proposals / session ideas on the following topics:

-Magic xpa Application Platform
-Magic xpi Integration Platform
-Big Data, SQL migration, xml handling, data mapping, bTrieve/Pervasive flat file tips, etc.
-Mobile app development and integration
-Case studies with hands-on examples and under the hood tips will be given priority
-Hands-on workshop formats including how-to build a mobile app for a particular platform
-HTML merge and web application development
-Other topics with wide appeal in the Magic user community

Please register now and book your hotel rooms early. 

Creating a Mobile Customer Service or Help Desk App with Magic xpa Application Platform

Writing a basic Magic xpa Customer Service or Help Desk app for a mobile device could make a great weekend mobile app development project for a Magic xpa developer.

Magic xpa does a good job of making it easy to handle the huge variety of data types, by insulating you from the details of the implementation.  Magic xpa reduces the number of data attributes (often referred to as data types in many programming languages) that you will need to work with -- alpha, numeric, date, time, BLOB, logical, etc. are the most common. The Magic xpa programmer also does not need to specify how those variables are actually stored in memory or in a database as the application platform itself manages these repetitive and inconsequential details for the developer.

To create a mobile app for customer service or an employee help desk, a few tables that might typically be required are the user table, the ticket table, the solution table and the solution response table. Many other variations are possible, of course, depending on the complexity of service/help app required. We’ll take the time to detail the fields used in the user table and the ticket table. But keep in mind that the tables will all have relationships.

For the sake of efficiency both in data storage and application performance, you should avoid creating duplicate data. So if, for example, the solution proposed relates to a specific ticket, there is no need to store all the ticket details in the solution table. You can simply point to the unique identifier of the ticket table. This is the principle of data inheritance. The data inheritance or data model relationships in our example are shown here:

Now let’s look at the User Table and Ticket Table.

Typical Customer Service App fields – User Table

Field name*	Field attribute	Field description
PrimaryID	Numeric	The unique identifier for the record.
UserFirstName	Alpha	The first name for the record
UserLastName	Alpha	The Last Name for the record
UserEmail	Alpha	The Email for the record
UserMobilePhone	Alpha	The mobile phone number of the user or device.
UserEmployeeID	Numeric	An integer value containing the employee ID for this record
DepartmentID	Numeric	An integer value containing the department ID for this record

Typical Customer Service App fields – Ticket Table

Field name*	Field attribute	Field description
TicketID	Numeric	The unique identifier for the record.
Status	Alpha	The status of the service ticket, for example, this could appear to the user as a drop down list offering open, closed, pending, overdue, etc.
Severity	Alpha	The status of the service ticket, for example, this could appear to the user as a drop down list offering open, closed, pending, overdue, etc.
Subject	Alpha	Brief subject of the problem described in the record.
Description	BLOB	A detailed description of the service issue.
CreateDate	Date	Date record was created.
CreateTime	Time	Time record was created.

* The developer can use any name for these fields, the field names here are just examples. In addition to the above, you’ll want to think about tables that contain the problem, description, and BLOBs containing the communications between the service rep and the user (the solution and response table), as well as tables containing service rep information, etc.

The challenge in creating a mobile help desk or customer service app for end users is that screen space is very limited on most mobile smartphone devices. The user information should be entered once, and then it need not appear to the user again unless they request to change it, for example, the user may need to change their phone number or email address. If you wanted to pre-populate the UserMobilePhone field, in theory this can be queried using a user defined function such as  ClientOSEnvGet ('device_udf| UIDevice currentDevice’) on iOS, for example, or the user can simply enter their mobile phone number.

Once the user identity is established, the home screen for the mobile app should be the list of tickets with open tickets bolded or listed in red at top in order from most recent to oldest. Only two columns are needed, Ticket and Subject. The user can select a ticket and then the detailed ticket tab opens with the ability to scroll down through solutions and responses. On an iPhone, these could be displayed as colored speech/conversation bubbles whereas on the android you may choose to display in the more conventional android style.

I think its fair to say that creating a Mobile Customer Service or Help Desk App with Magic xpa Application Platform makes for a great intermediate level programming project. What will set the good CS apps apart from the bad ones? Creative features such as customer self service knowledge bases could create real differentiation. When the type of service involves parts and repairs, location information of the device becomes even more relevant. How might you utilize location knowledge in your app to locate parts? to locate service centers?  

What sets the great mobile enterprise application platforms (MEAP) apart from the others? Integration, unified development approach, enterprise-class scalability, security and reliability. 

Creating a Store Locator / Store Finder mobile app with Magic xpa

Consumers need to be able to find your store locations from any location. Retail location awareness is part of the basic DNA of any retail chain. Writing a basic Magic xpa Store Locator app for a mobile device should be a fairly straightforward effort for an experienced Magic xpa developer. A basic Store Finder or Store Locator application has an input table and an output table. This is no different for the mobile app. 

The input table is the information provided by the user.

Typical input fields

Field name*	Field attribute	Field description
LookupRecordID	Numeric	The unique identifier for the record
Address1	Alpha	The street address of the record
City	Alpha	The city of the record
State	Alpha	The state of the record
Postal	Alpha	The ZIP or Postal code of the record
Country	Alpha	The Country of the record

* The developer can use any name for these fields, the field names here are just examples.

Typical output fields

Field name*	Field type	Field description
Longitude	Alpha	The longitude of the output geocode
Latitude	Alpha	The latitude of the output geocode
Quality	Alpha	The quality of the output geocode
Coordinates	Alpha	The coordinates of the reference polygon
StatusOK	Alpha	Debugging info from the geocoding process

With the Magic xpa Application Platform,  the developer can create mobile client apps that leverage the devices' GPS. With Apple iOS devices, for example, the ClientOSEnvGet function can be used to query the current device location using the internal or connected GPS device. Function syntax in the Magic Application Platform is selected in an intuitive table driven development wizard interface. So for example,  

ClientOSEnvGet (‘device_location’) will return the current device location, using available location options such as GPS or Network. The result is an ALPHA string in the following format: “OK|Latitude|Longitude”, where OK is a fixed part for testing if a result was returned, and Latitude and Longitude are the coordinates of the current location. If a location could not be obtained, for any reason, an error message will be returned. The results of this function may be parsed to provide the StatusOK, Latitutde and Longitutde fields in the example above.

With your backend system, information for store locations may not be in an obvious place. Yes, it will have an associated address book table. In JD Edwards, for example, address book info is stored in a F0101 table. But not all F0101 records contain your store locations. These will also include employee addresses, customer addresses and other business units such as plants and distribution warehouses. The business unit info will be stored in the F0006 table in JD Edwards, Business Unit Master table  which Contains Business Unit Descriptions and Category Code Information. The Magic xpi Integration Platform will give you an easy way to query these and other tables needed to piece together the necessary information. Other ERP systems can be accessed in a similar fashion.

Magic xpa stores string information with an attribute of ‘Alpha.’ Alpha allows the storing of alphanumeric characters. In the Alpha attribute, Numeric characters are stored as a string. The Alpha attribute is the default attribute.

Magic xpa stores numbers with an attribute of ‘Numeric.’ The numeric attribute allows the storing of an integer or a decimal number. Magic xpa supports up to 18 digits, with the condition that the number of whole digits and decimal digits are each rounded up to the nearest even number.

In addition, you can determine where you may need to employ logical, date, Unicode, time, BLOB, OLE, ActiveX, Vector or .NET data attributes.

With these basics in mind, creating a Store Finder app or Store Locator app is very straightforward with Magic xpa. Enterprise Mobility for retailers becomes a rapid reality with Magic xpa Application Platform.