Access Control
A key feature of the JDesignerPro system is the integrated Access Control mechanism and how that binds with the application structure. What we mean by "application structure" is the menu hierarchy and screen modules, combined with user menu authorization. Together these form the application structure.
When you run JDesignerPro it requires a login, although the login can by turned off. This login can be done either automatically or with a User ID and Password. When you hit the web page that calls JDesignerPro the system first sends the login screen with the User ID and Password fields. You can have your users login as Guest or with a specific User ID. By default, JDesignerPro never requires a password for User ID "Guest". Anytime a user logs in as Guest, JDesignerPro will ignore the password and give the user whatever level of access you have assigned to Guest. If you do not wish to have anyone be able to login this way, simply deactivate the Guest user in the User Maintenance screen. For more details, see System Maintenance.
The deployment of screens within JDesignerPro is tightly integrated with user access. An unlimited number of people could each see a separate set of screens, simply based on their access level. For example, Jane, from Accounting, logs in and sees only the outstanding order screens but she has no update capability, Jim from Sales logs in and he gets to see only his own outstanding orders for his territory, while Jennifer, the Sales Manager, logs in and she sees all the territories with all the sales peoples orders. This is very easy to accomplish using JDesignerPro. All of these people can access this application or multiple applications from the one install of JDesignerPro on your server.
When you deploy a set of application screens you define user-access authorization codes for each menu and each tab within the menu. Then you match those authorization codes with peoples access levels. When someone logs in the JDesignerPro system shows them only the menus and tabs that match their access level. Matching user authorization codes and levels to those of the menus is how you create user groups. See the System Maintenance section for more detail.
When a new module is created, the developer must give a login User ID and Password to the database. This is done at the start of the builder on the Select Database screen. The User ID and Password used on the Select Database will be the one used to login to the database when your final applet is run unless the 'use JDP usename/password' option is chosen. The application end-users do not login to the database directly. They login to JDesignerPro which in turn logs in as your account to the database. Your users update, insert, delete and searching authorizations are controlled by the User Maintenance settings that you define under JDesignerPros System Maintenance area. JDesignerPro handles connection scalability through the JaggServer.
BulletProof created JDesignerPro to capture the inherent power of the Intranet and Java. To that end, removed is the necessity to install anything but a browser on your users and developers desktops. At the same time BulletProof added the ability to build many applications over that single server install and have those applications be served up to users "on-the-fly." You only need to install the JDesignerPro system once on a server. From this one install can be served any number of applications to any authorized users, anywhere.
The diagram below explains the JDesignerPro structure from the viewpoint of features and how they tie together. This diagram is meant to give you an idea of the combined development and deployment systems with JDesignerPro.
Take two personnel, Gina, a Manager, and Jeff, an employee. Gina has a browser on her desktop. When she wants to run the Time & Expense application they built with JDesignerPro, she points her browser to an internal URL. When she logs in, the JDesignerPro system recognizes her authorization level, as entered by the system administrator. At that same moment, Jeff logs into the same application by going to the same URL. However, he sees two different screen modules than Gina because his authorization codes are of a different level.
Java client A appears on top of Ginas browser while Java client B is sent to Jeffs browser, both handled by the same install of JDesignerPro on the server. Both applications were designed and deployed with that same JDesignerPro system with the Java Application Development feature shown in the diagram. This feature includes the entire building environment.
The Access Control and Authorization Levels feature is the key to serving applications that are sensitive to who logged in. The system administrator sets authorization codes for users, then sets the same codes for the application modules to be sent to those users. The System Maintenance and Menu Structure feature determines the hierarchy of the menus and will serve screen modules to users based on their authorization level. The menu hierarchy can have an infinite number of menus and levels.
The Database Connectivity feature represents the automatic SQL generation and JaggServer, the JDBC-ODBC server integrated into your JDesignerPro system. The JaggServer also has server-side logic and handles scaling. JaggServer can scale up to ten thousand users with server upgrades. Other database servers can be accessed using JaggServer as long as ODBC or JDBC can recognize those servers from the machine on which JDesignerPro is installed. Future releases of JDesignerPro and JaggServer will allow you to build custom logic and timed events into the server. Currently the best method to use for database logic is to write stored procedures which can be called from the JDesignerPro client according to events there.