Abstract:
A system includes reception of a request from a client for application code to execute in a first Web page, determination that the application code is associated with a first UI framework, change of one or more Uniform Resource Locators of the application code to reference a portal server, change of one or more Uniform Resource Locators of the application code which are associated with the first UI framework to reference a first memory location of the portal server, the first memory location storing a plurality of files of the first UI framework, transmission of the changed application code to the client, and transmission to the client of a script to direct calls associated with the first UI framework to the portal server.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims benefit to and priority of U.S. Provisional Patent Application Ser. No. 62/058,465, filed Oct. 1, 2014, the contents of which are hereby incorporated by reference in their entirety for all purposes. 
     
    
     BACKGROUND 
       [0002]    Portal-based systems provide Web clients with a single point of entry to disparate backend applications, servers and/or services. The backend applications, servers and/or services may be implemented by one or more entities (e.g., a corporation, a public source, a Software-as-a-Service provider). 
         [0003]    User interface (UI) applications may be used to present information from these entities to a user via a Web client. In some cases, one portal page may present many applications that come from different locations.  FIG. 1  illustrates a portal-based system which supports UI applications. In operation, browser  110  calls portal server  120  using a Uniform Resource Locator (URL) associated with a page stored on portal server  120 . In response, portal server  120  transmits portal page  115  to browser  110 . Browser  110  parses page  115  and requests one or many applications specified in page  115  from application loader  124 . 
         [0004]    Application loader  124  acquires application code of the requested application and parses the application code to convert all URLs within the application code to URLs associated with proxy  122 . The application code may include javascript files, CSS files or any other file types containing relative or absolute URLs, and the conversion of URLs is done according to logic or semantics of the portal and proxy system. For example, a URL within the acquired application code may refer to one of applications/servers/services  130 - 134  of  FIG. 1 , and application loader  124  changes this URL to a URL of proxy  122 . The new URL may indicate the referred-to one of applications/servers/services  130 - 134 . Application loader  124  then provides the changed application code  117  to browser  110 . 
         [0005]    During execution, application code  117  may call one of the changed URLs, which results in transmission of a request to proxy  122 . Proxy  122  may then forward a corresponding request to a backend location indicated by the changed URL. Portal page  115  also includes XHRWrapper  119 . In a case that execution of application code  117  generates and calls a URL which was not explicitly specified in application code  117  (i.e., an AJAX call), XHRWrapper  119  overrides the native XMLHttpResponse function of browser  110  to direct this call to proxy  122  as illustrated. 
         [0006]    Increasingly, UI applications are developed based on UI frameworks. Execution of such a UI application requires access to files of its associated UI framework and may include requests for other resources of the UI framework. The above-described portal-based systems fail to efficiently support framework-based UI applications. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  is a block diagram of a system. 
           [0008]      FIG. 2  is a block diagram of a system according to some embodiments. 
           [0009]      FIG. 3  is a flow diagram of a process according to some embodiments. 
           [0010]      FIG. 4  is a block diagram of a system according to some embodiments. 
           [0011]      FIG. 5  is a block diagram of a system according to some embodiments. 
           [0012]      FIG. 6  is a flow diagram of a process according to some embodiments. 
           [0013]      FIG. 7  is a block diagram of a system according to some embodiments. 
           [0014]      FIG. 8  is a block diagram of a system according to some embodiments. 
           [0015]      FIG. 9  is a block diagram of a computing device according to some embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]      FIG. 2  is a block diagram of system  200  according to some embodiments.  FIG. 2  represents a logical architecture for describing processes according to some embodiments, and actual implementations may include more or different logical elements arranged in other manners. Each logical element may be implemented by computing hardware and/or by program code executed by one or more processors of one or more computing devices, but embodiments are not limited thereto. 
         [0017]      FIG. 2  illustrates client  210 , portal server  220  and resources  230 - 234 . Client  210  may comprise any client application configured to communicate with portal server  220  via any protocol that is or becomes known. According to some embodiments, client  210  is a Web browser and portal server  220  implements a Web server. Client  210  may comprise a proprietary dedicated application for communicating with portal server  220 . 
         [0018]    Portal server  220  includes proxy  222  and application/UI framework loader  224 . As a security-based limitation, client  210  is blocked from making Hypertext Transfer Protocol (HTTP) requests to servers other than the server from which a current page is loaded. Proxy  222  is intended to address this limitation. Proxy  222  may receive HTTP requests from client  210  and redirect those requests to one of resources  230 - 234  based on information contained in the request. Application/UI framework loader  224  may operate as will be described below. 
         [0019]    Each of UI framework configurations  242 - 246  includes data associated with a respective UI framework. The data may include a name/id/description of the associated UI framework, a library of files to support UI applications which are based on the UI framework and a script for redirecting calls from a UI application that are specific to the UI framework to an appropriate location of portal server  220 . Examples of UI frameworks that exist today are OpenUI5 and Angular JS. The following is a possible UI framework configuration in JavaScript Object Notation (JSON) format: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 { 
               
               
                   
                   name: “SAPUI5”, 
               
               
                   
                   fileLocation: “ui5”, 
               
               
                   
                   AvailableRevisions: [“1.5”, “1.6”, “1.7”], 
               
               
                   
                   proxyScriptClient: “ui5_xhrwrapper_hook.js”, 
               
               
                   
                   proxyScriptServer: “” 
               
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
         [0020]    UI framework configurations  242 - 246  may be located within portal server  220 , or one or more of UI framework configurations  242 - 246  may be remote from but accessible by portal server  220 . As illustrated in  FIG. 2 , client  210  has issued a request to portal server  220 . The request may comprise an HTTP request to a URL associated with portal server  220 . In response, portal server  220  transmits portal page  215  to browser  210 . According to some embodiments, it will be assumed that portal page  215  specifies one or more UI applications which are intended to be loaded and executed for display within portal page  215 . Accordingly, client  210  parses the code (e.g., Hypertext Markup Language (HTML)) of portal page  215 , encounters an identifier (e.g., a URL) of a UI application to be loaded, and issues a corresponding request to proxy  222 . 
         [0021]      FIG. 3  comprises flow diagram of process  300  for responding to such a request according to some embodiments. In some embodiments, various hardware elements of system  200  execute program code to perform process  300 . In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software. 
         [0022]    Initially, at S 310 , the request is received at the portal server. The request is received from a Web client and is a request for a Web application to execute in a first Web page.  FIG. 4  illustrates process  300  according to some embodiments. As shown, application/UI framework loader  224  receives a request for application code from portal page  215 . 
         [0023]    Next, a UI framework associated with the Web application is determined at S 320 . According to some embodiments of S 320 , application/UI framework loader  224  retrieves the application code from a local or remote repository. Although application/UI framework loader  224  and proxy  222  are described herein as performing several functions, one or more of these functions may be performed by the other or by one or more other components of portal server  220 . Continuing with the present example, application/UI framework loader  224  then parses the application code to determine the UI framework based on which the application was developed. In this regard, the UI framework may be identified by name and version within the application code. 
         [0024]    Files of the determined UI framework are loaded into a location (e.g., a folder) of portal server  220  at S 330 . Referring to  FIG. 4 , it is assumed that the UI framework identified at S 320  is associated with UI framework configuration  244 . Application/UI framework loader  224  therefore retrieves files of the UI framework from a location of portal server  220  which is specified in the UI framework configuration  244  at S 330 . This location is illustrated in  FIG. 4  as UI framework files  226 . 
         [0025]    Application/UI framework loader  224  rewrites URLs of the application code to reference portal server  220  at S 340 . Any URLs of the application code which indicate a location of UI framework files are rewritten to indicate the location of UI framework files  226 . At S 350 , loader  224  transmits the rewritten application code  217  to client  210 , as described above. 
         [0026]    At S 360 , application/UI framework loader  224  also transmits additional code to client  210 . Injected code  218  is to redirect UI framework calls issued by executing application code  217  to other UI framework files or to backend application\server\service to portal server  220  via proxy  222 . These calls may include including framework-specific hooks and events. 
         [0027]      FIG. 5  illustrates operation of system  200  after execution of process  300 . Upon initial execution, application code  217  issues a request for files of its associated UI framework. The request may include a rewritten URL associated with proxy  222  or URLs directly associated with UI framework files  226 . Proxy  222  receives the request, and application/UI framework loader  224  retrieves the required files from files  226  and forwards the required UI framework files to client  210 , where the files are stored as UI framework files  212 . In some cases, the files are stored in a cache and available for next requests from client  210  for these files. 
         [0028]    During execution, application code  217  may dynamically create code to request UI framework files. Such requests are intercepted by injected code  218  and redirected to proxy  222  or directly to framework files  226  of portal server  220 . 
         [0029]    Application code  217  also executes to request resources from elements  230 - 234  by calling the rewritten URLs described above. AJAX calls made by executing application code  217  are intercepted by XHRWrapper  219  and redirected to portal server  220  as described above. AJAX calls made from the UI framework code are intercepted by XHRWrapper and handled by the injected code  218 . Any other application code or UI framework code that generates URLs dynamically is also handled by injected code  218 . 
         [0030]      FIG. 6  is a flow diagram of process  600  according to some embodiments. Process  600  assumes that a first Web application has already been provided to a Web client for execution in a first Web page. In this regard, a request is received at S 610  for a second Web application to execute in the first Web page. 
         [0031]    At S 620 , loader  224  determines a second UI framework associated with the second application. It will be assumed that the second UI framework is identical to the UI framework of the prior example, therefore flow proceeds from S 630  to S 640  to rewrite the URLs of the second Web application. Flow then continues to S 680  to transmit the rewritten second Web application to the Web client. 
         [0032]      FIG. 7  illustrates an embodiment of the foregoing, in which rewritten application code  217 B is stored by client  210 . Upon execution of application code  217 B, it is determined that required UI framework files are already cached locally at client  210 . This determination is made because the URLs of application code  217 B which reference the required UI framework files indicate the same location of portal server  220  (i.e., the location of UI framework files  226 ) from which UI framework files  212  were retrieved. Accordingly, the UI framework files are not requested from portal server  220 . Application code  217 B may dynamically create code to request additional UI framework files. If these additional files aren&#39;t already cached in UI framework files  212 , the request is intercepted by injected code  218  and redirected to proxy  222  or directly to framework files  226  of portal server  220 . 
         [0033]    Application code  217 B may also execute to request resources from elements  230 - 234  by calling the rewritten URLs described above. AJAX calls made by dynamic code of application code  217 B are intercepted by XHRWrapper  219  and redirected to proxy  222  as described above. 
         [0034]    It will now be assumed that process  600  executes again in response to a request for third Web application to be included in portal page  215 . A third UI framework associated with the third Web application is determined at S 620 . At S 630 , it is determined that the third UI framework is not identical to any previously-loaded UI framework. Accordingly, files of the third UI framework are retrieved from a second location (e.g., UI framework files  227 ) of portal server  220  specified by corresponding UI configuration  242  or  246  at S 650 , as illustrated in  FIG. 8 . 
         [0035]    Application/UI framework loader  224  then rewrites URLs of the application code to reference the portal server at S 660 . Also, URLs which reference the third UI framework are rewritten to reference the location of UI framework files  227 . Next, at S 670 , code  218 B to redirect framework calls of the third Web application to the second location is transmitted to the Web client. Injected code  218 B may be retrieved from UI framework configuration  242 - 246  which is associated with the UI framework of application code  217 C. Loader  224  then transmits the rewritten application code  217 C to client  210  at S 680 , as described above. 
         [0036]    As described with respect to application code  217 , application code  217 C initially issues a request for files of its associated UI framework, because these files are not locally-available to client  210 . The request includes a rewritten URL associated with proxy  222 . Proxy  222  receives the request and application/UI framework loader  224  retrieved the required files from files  227  and forwards the required UI framework files to client  210 , where the files are stored as UI framework files  214 . 
         [0037]    If application code  217 C dynamically creates code to request additional UI framework files, these requests are intercepted by injected code  218 B and redirected to proxy  222  or directly to framework files  228  of portal server  220 . 
         [0038]    Application code  217 C also executes to request resources from elements  230 - 234  by calling the rewritten URLs described above. AJAX calls made by executing application code  217 C are intercepted by XHRWrapper  219  and redirected to portal server  220  as described above. 
         [0039]      FIG. 9  is a block diagram of apparatus  900  according to some embodiments. Apparatus  900  may comprise a general-purpose computing apparatus and may execute program code to perform any of the functions described herein. Apparatus  900  may comprise an implementation of one or more elements of system  200 , such as portal system  220 . Apparatus  900  may include other unshown elements according to some embodiments. 
         [0040]    Apparatus  900  includes processor  910  operatively coupled to communication device  920 , data storage device  930 , one or more input devices  940 , one or more output devices  950  and memory  960 . Communication device  920  may facilitate communication with external devices, such as client  210  or resources  230 - 234 . Input device(s)  940  may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)  940  may be used, for example, to manipulate graphical user interfaces and to input information into apparatus  900 . Output device(s)  950  may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer. 
         [0041]    Data storage device  930  may comprise any device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory  960  may comprise Random Access Memory (RAM). 
         [0042]    Proxy  932  and application/UI framework loader  934  of data storage device  930  may comprise program code executable by processor  910  to provide any of the functions described herein with respect to proxy  222  and loader  224 . UI framework files  936  may comprise files  226  and/or  227  of  FIG. 8 . Data storage device  930  may also store data and other program code for providing additional functionality and/or which are necessary for operation thereof, such as device drivers, operating system files, etc. 
         [0043]    Other topologies may be used in conjunction with other embodiments. Moreover, each system described herein may be implemented by any number of computing devices in communication with one another via any number of other public and/or private networks. Two or more of such computing devices of may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each computing device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of system  200  may include a processor to execute program code such that the computing device operates as described herein. 
         [0044]    All systems and processes discussed herein may be embodied in program code stored on one or more computer-readable non-transitory media. Such media non-transitory media may include, for example, a fixed disk,a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state RAM or ROM storage units. Embodiments are therefore not limited to any specific combination of hardware and software. 
         [0045]    The embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations.