Developing Self -Service Web Applications with WOW Enterprise
Web applications can provide almost any type of service. Web self-service is the leading approach companies are using to increase customer satisfaction and reduce costs. Self service applications allow users to obtain and use information online that has typically required the help of a human representative. WOW provides businesses simple, yet powerful, means to develop these types of applications and this guide will show you how.
Banks allow customers to sign on to a secure Web environment and obtain account balances, pay bills, or view transaction history. Insurance companies provide immediate rate quotes, billing information, and agent services on the web. E-commerce is becoming heavily utilized for selling everything from toothbrushes to real estate. Vendors and suppliers can make real time changes to purchase orders without the use of the phone or fax. These types of services are becoming more prevalent and the reason is obvious….. Companies save a lot of cash. “Self Service” applications provide lower overhead, increased user satisfaction and loyalty to a generation of “tech savvy” consumers, customers, and vendors.
The bottom line in whether or not B2B or B2C applications are an option comes down to return on investment. If a solution requires lengthy consult time and services businesses will be reluctant to move to change. There are solutions available that are affordable and can allow organizations to utilize their own development staff to provide these user friendly, helpful sites to their user community. The self-service application pattern is repetitive. These types of applications require user authorization and authentication to supply or receive information from a data source. This is a very easy task for PlanetJ’s Web Object Wizard.
· Customer Access to Account Information (B 2 C)
o Customers are able to signon and access their account information such as banking transactions, account balances, and statements. Customers can create orders and interact with a company in an individual manner.
· Supplier/Vendor Access to Account Information (B 2 B)
o Suppliers and other external business entities are able to sign on and access their information such as purchase orders, inventory quantities, policies, claims, accounts, and related information.
· Internal Company Employees (B to E)
o Employees are able to access and mange information they are authorized to such as personal contact information, individual appraisals, commissions, sales data, etc.
WOW is an application development tool that is easy to use yet provides the power and sophistication to create complete self-service applications. WOW makes extensive use of industry standard SQL. This example will show development of a customer self-service application in a secure, individualized manner without ANY coding using WOW Enterprise. Specifically this example will show how to develop an insurance self-service application. An insurance agent is allowed to sign on and only access their own quotes, policies, claims, and customers. This pattern and example can be applied to ANY self-service need. Insurance is used as example for educational purposes. The following will guide you through the technical steps required to create the insurance self-service application.
Authentication is the process of allowing access only to the users who should be using the application. Typically, this is done by having the user enter a userid and password although WOW supports authentication by any combination of fields. WOW supports authentication through the use of operating system (Database) user profiles. In this model, the database system provides all the management of the userid and passwords. In many cases however, it is not desirable or possible to create user profiles for all users. This is common if users are not direct members or employees of your organization such as suppliers or customers. In this case, a standard approach is to store user authentication data in a secure database. This database has limited access and is secured using operating system techniques. Passwords may further be encrypted providing another level of security.
WOW provides a special operation type called “Authentication”. Programmers are able to provide an SQL statement for the authentication process. When a WOW application is executed that specifies an Authentication operation for the signon type and signon operation, WOW will prompt the user based on the Authentication’s SQL. The prompting may be for a userid/pwd or an agent number or an email/pwd or a secret code. The capability and power of this should not be underestimated. It is easily possible to require authentication by entry of ANY combination of values and further those values can be directly used when returning data to that user. If an authentication operation returns a row of data, it is considered to be a valid logon attempt since they have passed the criteria of the authentication. The data returned from a valid authentication operation is stored in a secure session area for the duration of the user’s browser session. This user property data can be later used when restricting query criteria.
This is our user authentication table
The table shows the user names and passwords for those allowed access to our application. It demonstrates our company’s agents but could represent managers, vendors, suppliers, teachers, etc. Other user ID examples would include email, SSN, etc. Any relational table would work.
Using the information in the table above, the Authentication Operation written in SQL will provide the simple step of securing and self-service enabling the application. After creating your WOW application, from the WOW builder create a new operation. If you are not familiar with basic WOW development, please refer to WOW Security Protocols chapter in the WOW Builders Guide.
The SQL in the Operation Code reads: SELECT * FROM pjins63.user WHERE URNAME = ? and URPASSWORD = ?
This is shown in the example below.
By entering this authentication operation, the end user will need to enter a value for username (URNMAME field) and password (URPASSWORD) that matches a table record in the user authentication table in order to access the application’s operations. If they do not, they will not be provided access. Then, the operation must be assigned to an application as shown here. It is assigned to the “agent portal” application:
Take special note that the authentication operation can specify ANY criteria and can use ANY file or combinations of files via SQL joins. For example, the following table shows some possible authentication operations and provides a description of the behavior for each.
Select * from lib.tbl where userid = ? and password = ? and location = ?
Requires users to specify a matching userid, password, and location for access. All the values (userid, password, location, and any other field from that row) could be used in follow-on SQL operations.
Select * from lib.tbl where secret_code = ?
Anyone knowing the “value”’ of a secret code field would be allowed access.
Select * from lib.tbl, lib.tbl2 where tbl.userid = tbl2.userid and tbl.userid = ? and tbl.password = ?
Allows joining of two files to provide more information on the current user. Often used in cases where existing files hold user info but do not have a password. In this situation, it is common to create a new file with user password info and then join to existing information.
Select * from lib.tbl where userid = ? and password = ? and current time > ’17:00’
In this case, the user authenticates against a userid and password challenge and the system also checks that it’s AFTER 5PM! This could be used in a situation where an application shouldn’t be used until after normal business hours.
Select * from lib.tbl where userid = ? and password = ? and enabled = ‘T’
In this case, the user authenticates against a userid and password challenge and the system also checks that the “enabled” field contains a ‘T’. This could be used in a situation where an administrator toggles on or off a user’s access to the application. For example, if a user is suspended for disciplinary reason, they are no longer able to access the application.
Once authentication is complete, the individual agent will be welcomed to the application and be able to access and enter only his/her quotes and claims as seen here. The agent will then navigate the drop down menu at the top of the screen to manage, look up, or enter insurance quotes.
For the agent to view only his/her quotes a SQL operation is created with the following Operation Code:
SELECT * from pjins.quotes where agentid = ???urownerid
WOW looks for the occurrence of ??? (3 question marks) followed by a field name FROM THE ROW RETURNED BY THE AUTHENTICATION operation. In this example, the field UROWNERID holds the agent’s number. Once found the user property actual value is substituted in the place of the ???UROWNERID. For example, for agent 102, the value 102 would get substituted. This effectively limits the data returned to contain ONLY data for the current agent. Each agent authenticating would have a different agent number and therefore ONLY see THEIR data! This capability provides WOW easy yet powerful self-service functionality and can be applied to many application types.
As demonstrated, only the accounts with agent 102 (Nicole Jensen) are returned. Many additional variations of the self service SQL operation can be easily created as shown below:
Step 2 Creating User Specific Operations
SQL Operation Examples
Select * from lib.claims where agentId = ???UROWNERID and claim_date > ?
Selects insurance claim records for the current authenticated agent with a claim date greater than a user prompted value.
Select * from lib.policies where agentId = ???UROWNERID and policy# =
Selects insurance policy records for the current authenticated agent with a policy number equal to a user prompted value (I.E. The agent would enter a policy number).
Update lib.table set password = ? where agentId = ???UROWNERID
Allows the agent to update their own password. They will be prompted for the new password.
*Substitute your own tables or files and logic into these statements.
WOW Makes Self Service Easy as 1,2,3….
Self-service applications provide businesses a great way to increase customer satisfaction and reduce operating costs. Creating self-service applications up to this point has been extremely expensive and time consuming requiring manual and complex Java coding. WOW Enterprise Edition changes that allowing easy and fast development of self service applications.
Typical WOW powered self service applications can be built in less than 2 hours. This is just an example of basic self service but there much more complex self service Applications that can be created using WOW’s built in features. Contact your business partner or PlanetJ about how you can WOW your users.