Abstract:
A data validation procedure may be propagated to a server machine and to a client machine to perform the same data checking in the respective machines. The data validation procedure may be converted and expressed in a specification language that is suitable for the server machine. Likewise, the data validation procedure may be converted and expressed in a specification language that is suitable for the client machine.

Description:
BACKGROUND 
       [0001]    Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application, and are not admitted to be prior art by inclusion in this section. 
         [0002]    Typically, access to enterprise data is made via business applications. Business applications may be used to allow enterprise personnel (e.g., managers, sales people, etc.) to access the enterprise data from their computing devices such as workstations, mobile devices, and the like. Business applications may be used to allow customers to access the enterprise data. For example, a customer may make an online sales order, check on pending orders, update their contact information, and so on. 
         [0003]    Increasingly, access to the enterprise data is made over public communication networks such as the Internet. Accordingly, adequate data checking/validation is often required to ensure that valid data is provided to the enterprise to protect against inadvertent or purposeful corruption of the data. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0004]      FIG. 1  illustrates a general embodiment in accordance with the present disclosure. 
           [0005]      FIG. 2  illustrates an example of a web-based embodiment in accordance with the present disclosure. 
           [0006]      FIG. 3  illustrates processing in accordance with the present disclosure. 
           [0007]      FIGS. 4 and 5  show simplified examples of HTML code according to embodiments of the present disclosure. 
           [0008]      FIG. 6  illustrate a computer system that may be used in embodiments of the present disclosure. 
       
    
    
     DETAILED DESCRIPTION 
       [0009]    Disclosed embodiments relate to methods and apparatus for data validation in a client/server architecture. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be evident, however, to one skilled in the art that the present disclosure as expressed in the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein. 
         [0010]      FIG. 1  shows a high level generalized configuration of an enterprise system in accordance with embodiments of the present disclosure, comprising a development system  102 , a server system  104 , and a client system  106 . In some embodiments, the development system  102  may be a component in the server system  112 . In other embodiments, the development system  102  may be separate from the server system  112 , and in communication with the server system and/or the client system  114  over a suitable communication channel. In accordance with principles of the present disclosure, a data validation procedure  104  (e.g., developed on the development system  102  may be provided to the server system  112  and to the client system  114  using various mechanisms, which will be described below. 
         [0011]    In particular embodiments, the server system  112 , for example, may be an enterprise server hosting one or more backend business applications  122  of the enterprise. The client system  114  may be a computing device executing a frontend application  124  for accessing one of the business applications  122 . In embodiments, the client system  114  may be a personal computer (e.g., desktop or laptop computer, etc.), a mobile computing device (e.g., mobile phone, computer tablet, etc.), and so on. The frontend application  124  may use any suitable communication protocol whether public (e.g., the Hypertext Transport Protocol, HTTP) or a proprietary protocol to communicate with the business application  122  over a suitable communication network  116  such as the Internet, a local area network, a wide area network, and so on. 
         [0012]    In accordance with principles of the present disclosure, the first data validation procedure  104  may be developed on development system  102  and used to specify data validation processing for the business application  122  and for the frontend application  124 . A developer, may develop or otherwise provide the first data validation procedure  104  on development system  102 . 
         [0013]    In some embodiments, the first data validation procedure  104  may be expressed in a first specification language. For example, the first specification language may be rules based. Table 1 below shows an illustrative example for validating data relating to an address (e.g., zip code, a country name) using rules. The example shows a matrix based rule that expresses data formatting rules for the zip code and the country name: 
         [0000]                                      TABLE 1                           zip; NUM; 5; ;           country; ALPHA; ;50                END TABLE 1                        
The rules in Table 1 specify that the zip code (identified by the field name “zip”) is numeric data (“NUM”) and exactly 5 digits long, and that the country name (identified by the field name “country”) is an alpha string (“ALPHA”) that can be up to 50 characters long.
 
         [0014]    In other embodiments, the first specification language may be a scripting language. Table 2 below, shows an illustrative example of scripting language: 
         [0000]                                                                              TABLE 2                           If ‘Country’=‘DE’                CheckLen(‘ZIP’, 5, “Zip code length must be 5”)                Else                CheckMaxLen(‘ZIP’, 7, “Max zip code length is 7”)                End if           CheckType(‘ZIP’, ‘NUM’)           CheckDate(‘POSTDATE’ &lt;= ‘TODAY’)                END TABLE 2                        
In still other embodiments, more generally, the first specification language may be any suitable language for specifying a data validation procedure.
 
         [0015]    In accordance with the present disclosure, as illustrated in  FIG. 1 , the first data validation procedure  104  may be converted to produce a second data validation procedure  106  that is expressed in a second specification language. In some embodiments, the second specification language is different from the first specification language. For example, while the first data validation procedure  104  may be written in a rule based or scripting language, the second data validation procedure  106  may be expressed in a programming language that is suitable for the server. Examples of suitable server-side programming language/models include Java, C++, Personal Home Page scripting language (PHP), Advanced Business Application Programming language (ABAP), and so on. In some embodiments, the second data validation procedure  106  may be incorporated into the business application  122 ; for example, as a subroutine within the business application. In other embodiments, the second data validation procedure  106  may be a shared library module separate from the business application  122 , and accessed by the business application at runtime, for example, using a dynamic linking mechanism. 
         [0016]    Further in accordance with the present disclosure, the first data validation procedure  104  may be converted to produce a third data validation procedure  108  that is expressed in a third specification language. In some embodiments, the third specification language is different from the first specification language. The third data validation procedure  108  may be incorporated with the frontend application  124  in a similar manner as the second data validation procedure  106  is incorporated with the business application  122 . The third specification language, for example, may be JavaScript code, HTML/CSS, etc. 
         [0017]    In accordance with the present disclosure, the developer may test and otherwise assess their data validation design by running a test suite (e.g., using test automation) on the first data validation procedure  104 . Since the second and third data validation procedures  106 ,  108  derive from the first data validation procedure  104 , the test suite need only be run once. 
         [0018]    As indicated in  FIG. 1 , the first data validation procedure  104  may be provided directly to the client system  114 . This configuration may be suitable for embodiments where the frontend application  124  is a user interface (UI) that is customized for accessing the business application  122 . In other embodiments, the frontend application  124  may be a web-based application (e.g., web browser), and the business application  122  may include a web interface that can provide access to the business application via the web browser. This is shown in  FIG. 2 . 
         [0019]      FIG. 2  illustrates a configuration in which the frontend application  124  is a web-based UI. In some embodiments, for example, the frontend application  124  may be a conventional web browser such as the Microsoft® Internet Explorer° web browser, the Mozilla° Firefox° web browser, etc. The business application  122  may include a web interface  222  that the web browser frontend  124  can communicate with. In particular, the web interface  222  may send a web page  224  to the web browser fronted  124  that includes the third data validation procedure  108  expressed in a suitable specification language such as JavaScript code, HTML/CSS, and the like. In other embodiments, more generally, the frontend application  124  may be any suitable web-based application. The web interface  222  may provide the third data validation procedure  108  as a web service; e.g., based on a Representational State Transfer (REST) architecture, based on Web Services Description Language (WSDL), and the like. 
         [0020]      FIG. 3  illustrates high level handling of the first data validation procedure  104  in accordance with principles of the present disclosure. In a block  302 , the first data validation procedure  104  may be developed using a first specification language. As explained above, for example, a developer on development system  102  may develop the data validation procedure  104  using a scripting language or a rules based language. The language may be a commercially available product, or may be a proprietary system. The data validation procedure  104  may perform data checking, data verification, data cross-checking, and any other kind of validation that may be needed for the particular business application (e.g., business application  122 ) for which the data is being validated. 
         [0021]    In a block  304 , the development system  102  may generate a second data validation procedure  106  from the first data validation procedure  104 . In some embodiments, the development system  102  may provide the first data validation procedure  104  to the server system  112 , where the server system generates the second data validation procedure  106 . In other embodiments, the development system  102  may generate the second data validation procedure  106  and then provide the second data validation procedure to the server system  112 . 
         [0022]    In accordance with the present disclosure, the second data validation procedure  106  may be expressed in a specification language different from the specification language that is used to express the first data validation procedure  104 . In some embodiments, for example, block  304  may include translating the specification language of the first data validation procedure  104  into the server-side programming language that was used to build the business application  122 . As an example, if the business application  122  is written in the C++ programming language, then the second data validation procedure  106  may be expressed in C++ and compiled along with the business application  122 . Data validation processing in the business application  122  may then be conducted as defined in the first data validation procedure  104 . 
         [0023]    In a block  306 , the server system  112  may execute the second data validation procedure  106 . In some embodiments, for example, if the second data validation procedure  106  is expressed in a procedural language (e.g., C++), then the second data validation procedure may be compiled into the binary code comprising the business application  122 . The resulting executable code may then be executed on the server system  112 . In other embodiments, for example, the compiled procedure may configured as a shared library module that can be dynamically linked by the business application  122 . 
         [0024]    In a block  308 , a third data validation procedure  108  may be generated from the first data validation procedure  104 . The third data validation procedure  108  may be expressed in yet a third specification language that is different from the first specification language. For example, if the frontend application  124  is a Java-based application, the third specification language may be JavaScript code or HTML/CSS, and the like. 
         [0025]    In some embodiments, the third data validation procedure  108  may be generated by the server system  112  and pushed to the client system  114 . In other embodiments, the development system  102  may generate both the second and third data validation procedures  106 ,  108  and provide them to the server system  112 . The server system  112  may then push the third data validation procedure  108  to the client system  114 , where it can then be executed by the frontend application  124  (e.g., web browser) in a block  310 . 
         [0026]    Referring now to  FIGS. 4 and 5 , web-based examples of data validation processing will be explained. Suppose the first data validation procedure  104  comprises the following rule for data checking: 
         [0000]                            TABLE 3                            zip; NUM; 5; ;           END TABLE 3                        
As explained above, where the frontend application  124  is a web-based application (e.g., a web browser), the server system  112  may convert the first data validation procedure  104  to produce the third data validation procedure  108 , which can then be pushed to the client system  114 .
 
         [0027]      FIG. 4  shows an example of how the data validation procedure  104  may be expressed as HTML code. The figure illustrates HTML code  400 , which the frontend web browser application  124  can use to render a web page for receiving input data from a user. The HTML code  400  includes a section  402  that expresses the data validation procedure  104  shown in Table 3 as data in an array called valArray[ ]. A section  404  defines an interpreter function called Validate( ) which comprises code (not shown) that can interpret or otherwise execute the rules specified in valArray[ ]. A section  406  represents the body of the HTML code. The body invokes the Validate( )function when a mouse click event is detected in order to validate the input data. 
         [0028]    The approach illustrated in  FIG. 4  uses an interpreter, namely Validate( ) to process an array (e.g., valArray[ ]) that contains the rules set forth in the first data validation procedure  104 . The array valArray[ ] may be initialized by the server system  112  with coding from the first data validation procedure  104 . Data validation is performed when the client system  114  invokes the interpreter function Validate( )to run through the contents of the array valArray[ ]. 
         [0029]    In other embodiments, the data validation procedure  104  may be expressed as a customized validation function in the HTML code. Referring to  FIG. 5 , HTML code  500  comprises a validation function  504 , which defines the validation function Validate( ) and a body section  506  having code that invokes the validation function. The validation function Validate( )contains code generated in the server system  112  that is specific to the procedure set forth in the data validation procedure  104 . 
         [0030]    The examples illustrated in  FIGS. 4 and 5  validate data when the data is submitted; e.g., by clinking an OK button. In other embodiments, data validation may be performed when the user leaves a data input field; e.g., by hitting the TAB key to go to the next data input field. 
         [0031]      FIG. 6  shows an illustrative embodiment that may be used to implement any or each of the development system  102 , the server system  112 , and the client system  104 . The embodiment may include a computing component  602  having a processing unit  612 , a system memory  614 , and a system bus  611 . The system bus  611  may connect various system components including, but not limited to, the processing unit  612 , the system memory  614 , an internal data storage device  616 , and a communication interface  613 . In the case of a client system  114 , the embodiment may be a mobile computing device. 
         [0032]    The processing unit  612  may comprise a single-processor configuration, or may be a multi-processor architecture. The system memory  614  may include read-only memory (ROM) and random access memory (RAM). The internal data storage device  616  may be an internal hard disk drive (HDD), a magnetic floppy disk drive (FDD, e.g., to read from or write to a removable diskette), an optical disk drive (e.g., for reading a CD-ROM disk, or to read from or write to other high capacity optical media such as the DVD, and so on). In a configuration where the computing component  602  is a mobile device, the internal data storage  616  may be a flash drive. 
         [0033]    The internal data storage device  616  and its associated non-transitory computer-readable storage media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth. Although the description of computer-readable media above refers to a HDD, a removable magnetic diskette, and a removable optical media such as a CD or DVD, it is noted that other types of media which are readable by a computer, such as zip drives, magnetic cassettes, flash memory cards, cartridges, and the like, may also be used, and further, that any such media may contain computer-executable instructions for performing the methods disclosed herein. 
         [0034]    The system memory  614  and/or the internal data storage device  616  may store a number of program modules, including an operating system  632 , one or more application programs  634 , program data  636 , and other program/system modules  638 . For example, where  FIG. 6  represents an implementation of development system  102 , the application programs  634  may constitute a development system to develop data validation procedure  104 . Where  FIG. 6  represents an implementation of server system  112 , the application programs  634 , which when executed by computing component  602 , may cause the server system to perform steps shown in  FIG. 3 ; likewise, when  FIG. 6  represents an implementation of client system  114 . 
         [0035]    Access to the computing component  602  may be provided by a suitable input device  644  (e.g., physical or virtual keyboard, mouse, touch pad, etc.) and a suitable output device  646 , (e.g., display screen). In a configuration where the computing component  602  is a mobile device, input and output may be provided by a touch sensitive display. 
         [0036]    The computer system  602  may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers (not shown) over a communication network  652 . The communication network  652  may be the Internet, a local area network (LAN) and/or larger networks, such as a wide area network (WAN). 
       Advantages and Technical Effect 
       [0037]    Advantages an technical effects of embodiments according to the present disclosure will now be discussed. Typically, data validation should be conducted at the backend (e.g., server system  112 ) because client data cannot be considered trusted; e.g., due to a compromised frontend (e.g., hacked browser), man-in-the-middle attacks, and the like. However, the conventional approach of providing data validation only at the backend can lead to degraded performance since each time a data validation action is triggered, a round-trip communication from the frontend (e.g., client system  114 ) to the backend and a return trip to the frontend is required, which can significantly degrade performance. 
         [0038]    A conventional solution includes performing some data checking on the frontend. However, as explained above, data validation still must be conducted on the backend because of possibly compromised frontend. In addition, certain data validation checks may be possible on the frontend because the program language used by web browsers (e.g., JavaScript, HTML/CSS, etc.) may limit what kind of data validation processing can be performed. 
         [0039]    Typically, the developer develops and maintains two data validation programs, one set of procedures developed for the backend software (e.g., the business logic) and another set of procedures developed for the frontend (e.g., browser web pages). This can result in high development costs because the backend software is typically implemented in a language (e.g., ABAP, C++, Java, etc.) that is different from the frontend code (e.g., JavaScript code), and possibly by different development teams. Developing and managing separate data validation procedures can result in inconsistent treatment of data; e.g., data that is deemed valid by the frontend may be deemed invalid by the backend and vice versa. Over time, the frontend data validation procedure and the backend validation procedure may get out of sync in terms of what is deemed valid, what data is checked, and so on. 
         [0040]    In accordance with principles of the present disclosure, the data validation procedure that is performed in the server system  112  and the data validation procedure that is performed in the client system  114  are obtained from a single source, namely the data validation procedure  104 . As can be appreciated, embodiments according to principles of the present disclosure avoid round-trip processing by providing for data validation to be made in the frontend. Having a common source of the data validation procedures prevents deviation of the procedures that are performed in the frontend and the backend. Also, a common source of data validation procedures results in lower maintenance costs by virtue of a single development and support effort. In addition, automated test suites need only be developed for the source data validation procedure  104 . In addition, further checks can be performed on the backend, which cannot be done on the frontend. 
         [0041]    The above description illustrates various embodiments of the present disclosure along with examples of how aspects of the particular embodiments may be implemented. The above examples should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the particular embodiments as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents may be employed without departing from the scope of the present disclosure as defined by the claims.