Patent Application
20120166983
The field generally relates to the software arts, and, more specifically, to methods and systems for integrated metadata and nested authorizations in a user interface framework.
Many Web application frameworks follow the Model View Controller (MVC) architectural pattern to separate the data model with the business logic from the user interface. The MVC pattern modularizes code, promotes code reuse (use of existing software code, or software knowledge, to build new software code), and allows multiple interfaces to be applied. The MVC architecture consists of a model, a view, and a controller. The model part of the MVC pattern is a domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can refresh. The view of the MVC pattern renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. The controller of the MVC pattern receives input and initiates a response by making calls on model objects. When a Web application user interface framework is built on the MVC architectural pattern approach, high speed development of uniform user interfaces (UIs) is possible.
Generally, a Web application UI framework works with and maintains business data in the user interface components and in parallel maintains every business object, method, and action access manually as a rule directly in a policy stored in a separate storage unit (independent of the UI components metadata). Thus, there are two types of metadata: one type of metadata describing the UI components and another type of metadata describing the authorizations to the business data. The metadata describing the authorizations could be very detailed and stored in a quite large file since the access to each business object from the business data may be described with an authorization rule in the policy. This leads to checking every time the authorization rule for obtaining access to the business object, method, or action. Maintaining two different types of metadata, for UIs and for authorizations, may cause additional maintenance efforts, decreased system performance, and slow response time of the application. Further, this may lead to inconsistencies between the UI components and the authorizations to the business data.
New combinations of UI components (e.g., building a new view from existing UI components) results in a new set of authorization rules, which have to be maintained manually, thus causing additional maintenance effort and inconsistencies. Also, in general metadata relations are not used for policy generation and for runtime adoptions based on authorizations and scoping. The policies are manually maintained. This may lead to inconsistencies, additional maintenance effort, and lack of flexibility.
Various embodiments of systems and methods for integrated metadata and nested authorizations in a user interface framework are described herein. In an embodiment, the method includes receiving a selection of a work center via a request and determining one or more workcenter views assigned to the selected work center, wherein a workcenter view is a generic view or an application view. A primary user interface component assigned to the workcenter view is retrieved. The primary user interface component includes authorization metadata. Finally, a dependent user interface component of the user interface application is retrieved, wherein the dependent user interface component is secured with a nested authorization via a metadata relation with the primary user interface component.
In an embodiment, the system includes a processor and a memory in communication with the processor. The memory comprising a work center structure including one or more workcenter views assigned to a user, wherein a workcenter view is an application view or a generic view. Further, the memory includes an integrated entity including a user interface application component metadata and authorization metadata. At least one dependent user interface component is embedded in the user interface application component and secured via nested authorization metadata. Finally, an identity business objects is included that stores workcenter views assignments.
These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The claims set forth the embodiments of the invention with particularity. The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for integrated metadata and nested authorizations in a user interface framework are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiment.
UI Framework Client Runtime 115 may be implemented in a programming language such as “C# using a RIA based framework such as Microsoft Silverlight® technology. The UI Framework Client Runtime 115 is responsible for rendering user interfaces and access business data from backend 120. Every user request is triggered on the UI Framework Client Runtime 115. The very first request is a navigation request that results in a request to the backend 120 to read a UI component. The UI component is read from the Repository 175 in the backend 120 and transported to the frontend 110. A component manager instantiates the UI component and a corresponding component controller 165 for the UI component on the frontend 110 and triggers the initialization of the UI component on the backend 120. The component manager builds up a control tree for the UI component out of a set of UI controls 150. These UI controls 150 ensure conformable look and feel and the ability to change UI themes consistently. The controls in the “themed UI controls” package are all enabled in a consistent way for test automation and accessibility, and are provided in a manner so that native implemented custom UI panes can make use of those controls. Usually, more than one UI component is needed to render a UI, as UI components typically embed other UI components (e.g., a Work Center component embeds a set of Workcenter View Components and they again embed other components). The top-level UI component that is rendered is the root UI component which makes sure to render a common frame for all UI components, e.g., by rendering the top level navigation and the ability for personalization from personalization unit 155.
In an embodiment, the UI Framework Client Runtime 115 also comprises the following built-in units: analytics 130, mashups 135, diagnostics 140, shell 145, and frontend scripting 160. Analytics 130 are components that represent data in a grouped, aggregated, and hierarchical way. These components serve to answer business questions about, for example, how many products were sold in a particular country and provide drill down capabilities to different level of abstraction. Diagnostics 140 allows the collection of, for example, the context of the current framework and all other running entities of the overall system at a specific point in time (e.g., in case of an exception or error). The collected information can help to track down the cause of the exception. Shell unit 145 provides the shell for running the UI Framework Client Runtime. It includes all units for the user interface ranging from defining the overall appearance of windows (including standard elements such as menus, toolbars, navigation areas, windows management) as well as the mediator layer that maps logical component definitions from the configuration model to physical controls. In addition, there are possibilities to use a Silverlight® feature to run the client in “out of browser” mode. Also, a prototype exists to run the client as a standard WPF desktop client in contrast to the Silverlight® browser plug-in. This requires some replacement of connectivity and authorization code, which is provided by the browser stack itself. Frontend scripting 160 enables data from the client side data model to be read, evaluated, and modified—which causes eventually configured events again in the runtime execution of the model. With these capabilities, UI-only logic can be expressed and modeled via some script; it is not required to implement or model the logic in the backend. Optionally, the script can be executed on the client or backend.
The frontend 110 communicates with the backend 120 via browser 167 on a regular HTTP/HTTPs connection 168 using JavaScript Object Notation (JSON) (also, other serialization formats such as XML can be used in parallel to JSON) as a lightweight data interchange format. The requests from the frontend 110 are received at Internet Communication Framework (ICF) 170. The ICF 170 forwards the requests to the UI Framework Server Runtime 125 and Repository 175. The Repository 175 stores all UI entities with their metadata. The UI Framework Server Runtime 125 reads and interprets the UI model of the application, manages the access to the backend and ensures an optimized communication with the UI Framework Client Runtime 115. After the UI Framework Client Runtime 115 triggers the initialization of a UI component in the backend 120 for a first time in a session, the UI Framework Server Runtime 125 first creates a master controller 180 for the complete session and then creates a component controller for each component that is requested from the UI Framework Client Runtime 115. Each component controller builds a UI data container out of the information of the UI model for a component. At runtime, the composition of the dependent components is combined within the master controller 180, which holds one event queue and performs data updates for all included components as one component. In an embodiment, logically separated declared components can be configured to run as one virtual controller at runtime.
After the master controller 180 has processed all component controllers, it collects all the data that has changed in the UI data container and makes sure that all changed data and only the changed data is transported to the client 110. The access from the UI Framework Server Runtime 125 to business data 190 is performed via connector 185. Connector 185 is able to connect to different technologies.
In various embodiments, there are different types of user interface (UI) entities including, but not limited to: work centers (WoC), workcenter views (e.g., application view, invisible application views, generic views, etc.), UI components, and so on. A work center is a semantic bracket of many workcenter views. A workcenter view is a business cluster of UIs of an application for which a user can be authorized. Work centers are based on application views and generic views. Generic views are user interface views such as “Overview” page in a business application, “reports”, and so on, that provide general information in the business application (aggregated information of application views). Application views are autonomous entities that are built for a special business scenario providing specific features in the business application. The work centers are built from a combination of generic views and application views. Common tasks in a business scenario are defined on view level and are aggregated from the assigned application views to a work center level. Different combinations of the application views can be assigned to a user. In addition, new work centers can be combined based on existing application views. In an embodiment, flexible usage of semantically defined UI entities without duplication the metadata and without combination restrictions is achieved. Further, different permissions to a user are allowed.
In various embodiments, start authorizations are used. This means that at startup of the application, the main UI application component is checked if it can be accessed by the user and all UI components that are embedded (nested) in the main UI application component are running in a privilege mode, meaning that they share the same authorization context with the main UI application component. If the main UI application component is accessible, then the embedded (dependent) UI components in this main UI application component are also accessible. In addition, since only the main UI application component needs authorization, then the metadata for the authorization is maintained only for the main UI application component and no metadata needs to be maintained for the embedded UI components. The UI framework runtime ensures the security of the nested UIs via the metadata relations. The metadata relations are used for authorization aspects during runtime and for policy generation.
Application views 230 include a set of metadata such as common tasks 235, navigation targets 240, reports 245, policy 250, exposed views 255, and so on. The application views 230 own all relevant metadata and can be reused in other work centers or combined in new work centers. Common tasks 235 metadata is analyzed and aggregated to the work center level (e.g., TaskListView metadata is analyzed and aggregated to the generic view MyWork 220). Object work lists that are integrated in the application views 230 are analyzed and aggregated to quick links UIs that are part of the Overview 215. Reports 245 are analyzed and aggregated to the Reports 225 views. Business tasks are analyzed and are aggregated to MyWork 220 view. Content that can be used for personalization is aggregated to the generic Overview 215. Navigation targets 240 are analyzed and registered in a navigation registry. Authorization rules in policy 250 are analyzed and are aggregated to a policy view. UI framework runtime determines what UIs are allowed for a user based on the aggregated information and displays only them.
The policy represents a set of rules (per UI Application) that allows the usage of the UI Application and defines which business objects should be checked in addition at runtime. Policies are defined at view level. No policies are generated for generic views, only for application views. A policy for an application view includes the authorization to launch the application view of a work center with the corresponding main UI component and dependent UI components. The policies for the application views are generated at runtime after scoping. Scoping is restricting (based on business decisions) the metadata relations which are used to create the policy. The policy generation can be triggered manually or automatically by the UI framework. The scoping decisions are made by the customer, in which he or she specifies which business functions are in scope of a given business scenario. Based on these decisions, the policy is updated and allows only the related UIs which are in scope to be accessed.
The included authorization metadata in the integrated entity 320, the policies, and the modeled assignments of the UI components are provided to a UI framework such as Role Based Access Management basic (RBAM) framework. The RBAM framework ensures that those BOs are accessed for which the user is authorized. A UI framework runtime such as the RBAM framework runtime 370 checks the UI Application 310 for access authorizations based on the integrated metadata 320.
The workcenter views may be generic views or application views. In an embodiment, a primary UI application component is assigned to the application view. At block 420, common tasks metadata is read from the retrieved workcenter views. At block 425, it is determined whether the primary UI Application component is accessible based on assigned authorization metadata. The primary UI application component includes assigned authorization metadata. Thus, the authorization metadata is integrated in the main (or primary) UI application component metadata. The main UI application component may include at least one dependent component as no authorization data is assigned to the dependent component. The authorization of the dependent component is based on the assigned authorization metadata to the main UI Application component. The dependent component runs in the access context of the main UI application component. If the user has access rights to the main UI Application component, then the user can access the dependent UI component as well via the nested authorizations. At block 430, if the primary UI Application component is accessible, then the primary UI Application component is added as common tasks to the selected work center. At block 435, the selected work center is rendered. At block 440, a default workcenter view is requested, without a new user request. If the default workcenter view is detected as an application view, the process continues at block 445. Otherwise, the process continues at block 465.
At block 445, the default workcenter view is detected as an application view with an assigned primary UI Application component. The embedded UI application components of the application view are read and the application view is rendered. At block 450, the embedded dependent UI components are requested, without a new user request. At block 455, the metadata of the main UI application component is adapted for the dependent components based on the nested authorizations. The business data of the dependent components is requested based on the assigned authorizations. At block 460, the embedded dependent components are retrieved by requesting them in the context of the primary UI Application component. The requested business data is retrieved and generated in the work center.
At block 465, the default workcenter view is detected as a generic view. At block 470, the embedded default UI components of the generic view are requested for read. Since the generic view has no assigned policy (the authorizations are given by other views), it is determined if the embedded default UI components are authorized. If an embedded default UI component is not authorized, it will be removed. At block 475, exposed content for which the user is authorized (from other views, e.g., application views) is automatically aggregated and added as personalization content in the generic view. At block 480, the generic view is rendered. The embedded UI components (which are not UI application components) are requested. The content of the UI components is aggregated from the authorized views and the relevant content. The corresponding metadata and business data is displayed.
At some point in time, the user 505 decides to start the application to view or edit some data. The application is accessed by entering logon data such as a user name and password in user interface 540. After the logon, the UI 540 forwards the user request to work center provider 545. The work center provider 545 handles (e.g., selects, stores, adapts based on authorizations, scoping, and so on) the work center models at design time and runtime. The work center provider 545 retrieves the related design time metadata from navigation repository 550 and is adapts the metadata based on the authorizations (user-Workcenter-View assignments) and based on the scoping decisions. In an embodiment, navigations are handled as indirect navigations. This means that a target UI is not directly retrieved. Instead, a source UI triggers an abstract navigation (business object and operation, e.g., SalesOrderBO-Open) and the UI framework detects based on the authorizations, scoping, etc., which targets are allowed and what UI is launched.
The assigned work centers (e.g., control center 510, account management 515, and new business 525) and workcenter views (e.g., 510_1, 510_2, 510_3, 515_2, 525_1, and 525_3) are retrieved from the navigation repository 550 based on the identity business object and scoping decisions and sent to the work center provider 545. The work center provider 545 forwards the assigned WoCs and WoC views to the UI 540. The UI 540 displays the assigned WoCs and WoC views to user 505 based on the user authorizations and the scoping decisions.
Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source 660 is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
