Reason #17: Magic xpa has a Built-In Licensing Mechanism

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

One of the deficiencies of C# as it compares to Magic xpa is that it lacks any sort of licensing mechanism. Licensing is important for software publishers who want to use Magic xpa to create and protect commercial software. It also provides an added measure of security and risk prevention to corporate software users. Licensing mechanisms help to prevent unlicensed software usage and therefore reduce the risk that a company can be sued for copyright and other violations. When considering migration of Magic eDeveloper to C#.NET or ASP.NET or Java (or uniPaaS or Magic xpa), it is important to consider your need for licensing mechanisms.

 Magic xpa’s built-in license-metering mechanism uses your local area network (LAN) to communicate between Magic xpa instances running on different machines on the network. As part of our ongoing commitment to comply with the latest and highest industry standards, Magic introduced a new policy for the activation of our software licenses in 2012. The improved process, implements a highly secure, automated method of license protection, enabling you to better monitor the use of your licensed software.

You activate and receive your licenses after validating your Product Key on Magic’s License Activation Portal. The metering mechanism helps organizations avoid any unintentional violation of the license. The license-metering module ensures that no more than the allowed number of connections uses Magic xpa concurrently.

Magic xpa includes a license management scheme. The license management system comprises three main components: a License File, which stores all the license information for a specific site; the Magic xpa Engine, which uses data from the License File to allow or prevent user access to an installed Magic xpa product; a License Server, which provides license information to the Magic xpa engine, and also counts the active users of the installed product.

Magic xpa offers three license modes: no license, demo license and permanent license. The Magic xpa License File, when initially created, contains a default demo license. This demo license has no time limit but is limited in its functionality and cannot be used for the development and deployment of mission-critical applications. Permanent licenses have no time limit. When you load Magic xpa with no license, essentially without specifying a license name, the Single User Edition will run.

The single-user limitation is relevant for both the development of the application, as well as its deployment. Magic xpa Single User Edition provides almost the complete range of features found in the commercial edition of Magic xpa, excluding multi-user related features and capabilities.

Magic xpa also includes convenient mechanisms for counting licenses and running floating licenses. To count licenses, you can run MGSTATIONS.exe from the Magic xpa directory to verify the license count of a specified license on a network.

Magic xpa's default behavior is that you have to define the number of licenses that each server uses during the execution of a project. This number is checked across all the servers in a multi-project environment to ensure that it is within the license limitation. For example, if you have a license with 20 threads, and you have two projects running in a multi-project environment, you have to distribute the threads in advance. Project A might receive 15 threads, while Project B receives 5.

In a multi-project environment, each server runs a different project. This means that the capacity of each server (project) is a key issue, and the ability to share licenses (threads/users) is very important.

Magic xpa's floating license mechanism lets you make optimum use of these licenses in a multi-project environment, by sharing licenses between servers. Therefore, when a particular project is idle, other projects can utilize its licenses.

Because the Magic xpa broker controls the servers and their capacity, it needs to know the total number of licenses that are available for its servers. The broker adds up the total maximum threads and users belonging to each server. The broker uses this figure as the total number of available threads/users. If the broker sees that a particular server is not using its allocated number of threads/users, the floating license mechanism means that they can be used by other servers.

Using C# to manually license software is a fool’s errand. Using C# to bind in a third-party licensing scheme is also very expensive and time consuming. The advantage of the Magic xpa Application Platform is that licensing is built-in to the platform as a protection to both corporate end users and software developers.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.

Reason #16: Straightforward Security Management

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Magic greatly simplifies security issues for developers, giving them the power to create highly secure applications without a lot of hassle. This is another reason why Magic eDeveloper or uniPaaS to .NET migration via C#.NET is a mistake compared to upgrading to .NET with Magic xpa.

User rights management is simplified in Magic because the developer and administrator/supervisor use Magic xpa’s built-in Authorization System, Active Directory or LDAP. The Authorization System enables developers and certain users to control access to Magic xpa projects in Studio modes. This control is achieved through setting access keys to various Magic xpa project elements, and by assigning specific rights to users and user groups.

As a repository based system, Magic xpa is vastly superior to the tedious coding required for rights management in C#. The Magic xpa Rights repository lists the name and keys of all the rights defined for a project. The developer can define a bank of rights and assign them to the project's various repositories and elements. Any project element that has an access right assigned to it will be blocked to users who have not been assigned this right. Project-layer security is always defined during development.

In addition, Magic xpa includes a flexible authorization system to control what each user can and cannot do in Magic xpa. The authorization system lets the application developer or system supervisor limit access to various activities in Magic xpa to those users specifically authorized to have such access.

The authorization system exercises its control through sets of rights and the use of built-in Magic xpa functions. Rights can be thought of as keys to locks. Rights assignments connect users, who are classified by role, with the application’s components, which are classified by accessibility. This means that certain classes of users are allowed to access certain parts of an application.

The person in the role of Supervisor can assign rights that give each user access only to the activities for which that user is authorized. Any activity that is not specifically restricted by the Supervisor or the developer remains accessible to all users and does not require any rights assignment. To access the authorization system repositories, the developer must log on to the system as a user which has the SUPERVISOR GROUP assigned to the user. This group is reserved by Magic xpa, and is automatically included in any Magic xpa system. In addition, a Supervisor user (which has this group assigned to it) is also automatically included in any Magic xpa system.

Typically, when one is implementing a security system in Magic xpa, rights are granted according to the user’s job function, which corresponds to a Magic xpa Group. That is, a user who is a bookkeeper will have a different set of menus and screens than a person who is in Sales. Other rights, however, may only be granted to certain individuals, such as the ability to approve paychecks or adjust time cards.

Managing rights in C# can be like looking for a needle in a haystack. Instead of having to search through potentially millions of lines of code to find everywhere that a role is checked, Magic xpa provides a single, consolidated location known as the Rights Repository. What a nightmare it would be to have to parse an entire code base to learn and document what roles are assigned to what permissions.

For additional information on how an upgrade to Magic xpa is superior to Magic eDeveloper to .NET conversion please convert here.

Reason #9: C#.NET Manages Tab Order Poorly

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Reason #9: C#.NET Manages Tab Order Poorly

C#’s idea of tab order is to set the tab order in the order that the controls were created. As we all know, from experience designing forms. Controls often get moved around and arranged. The desired tab order is not oldest to newest, its left to right, top to bottom in order of z-depth. Right?

So if you were to convert your application from Magic to C#.NET instead of from Magic to Magic xpa on .NET, you are going to have to deal with this illogical tab order going forward. This is just an example of the thousands of idiosyncratic weaknesses of procedural coding in C#.NET versus .NET platform-based development in Magic.

Here’s how it works in Visual Studio C#.NET:

In Visual Studio C#.NET, the tab order is the order in which a user moves focus from one control to another by pressing the TAB key. Each form has its own tab order. By default, the tab order is the same as the order in which you created the controls. Tab-order numbering begins with zero. Keep in mind that this is a gross oversimplification. What we can describe about C#.NET behavior in one paragraph takes more than 20,000 lines of code in C#. In fact, just control.cs alone is that size. Good luck Magic programmers if you have to debug that C# source code. And yes, there are bugs in it!

Here’s how it works in Magic xpa:

When working in Automatic Tabbing Order, Magic xpa creates tabbing identifiers for every control on the form of an Online or Rich Client task, maintaining a consecutive sequence from 1 to the last supported control, regardless of whether the control allows the user to park or not. For a Browser task, the Automatic Tab Order command is always automatic.

When you place a new control or move an existing control on a form, Magic xpa sets or changes the tab order by the control’s top, left location, and Z-Order. When the form is set aligned right to left, Magic xpa sets or changes the tab order by the top, right location, and Z-Order.

For example:

When you place the first control at 2,2, the tab identifier is set as 1. When you place the second control at 3,2, the tab identifier is set as 2. When you place the third control at 2,4, the tab identifier is set to 2 and the tab identifier for the second control is reset to 3. Removing a control shifts all consecutive Tab Order properties one value back.

When working in Manual Tabbing Order mode is not active, Magic xpa lets you enter a four-digit identifier or set an expression that returns a numeric value in the Tab Order property that lets Magic xpa determine the tabbing order for the control in relation to other controls on the form.

So out-of-the-box, Magic’s automatic tabbing order makes much more sense and you gain very straightforward programmatic control of tabbing order as well including being able to set the tab order with an expression! How cool is that? If you wanted to do that in C#.NET, you would have to write the underlying code that would do that and it would need to interact with that 20,000 line code base we mentioned. In Magic, the application platform provides that capability for the developer built-in.

For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here.