TRANSFERRING PARAMETERS IN APPLICATIONS AND INTERFACES ACROSS MULTIPLE PLATFORMS

TECHNICAL FIELD

This description generally relates to user interfaces. The description, in particular, relates to systems and techniques for providing a user interface experience for viewing data and information related to multiple software applications.

BACKGROUND

A user of software applications designed to support processes used by an enterprise often needs to navigate back and forth between multiple (and in many cases different) user interfaces and application instances in order to carry out transactional tasks when making a viable decision for the enterprise. In many cases, the navigation can include viewing data and information related to multiple applications. While navigating between the various user interfaces and application instances, the user may become lost and confused, losing a context of a current transactional task. This can create major usability issues, resulting in the inability of the user to effectively carry out the transactional tasks. In general, the user has a poor user experience using and interacting with the software applications.

SUMMARY

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

One general aspect includes a computer-implemented method for populating and transferring parameters across a plurality of applications executable on multiple user interface platforms, the method including: receiving, at a server device, a request to launch a first application executing on a first user interface platform, accessing a plurality of parameter values and populating, with the plurality of parameter values, fields in user interfaces associated with the first application. Responsive to receiving a request to launch a second application executing on a second user interface platform, accessing a signature associated with the first application, determining that the signature matches a predefined signature associated with the second application, determining a portion of the plurality of parameter values that are applicable to the second application, generating at least one uniform resource locator representing the portion of the plurality of parameter values, transmitting the at least one uniform resource locator to the second application, and launching the second application, and populating for at least one user interface corresponding to the second application, a plurality of fields using the portion of the plurality of parameter values associated with the uniform resource locator. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs/products recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The method where the signature and the uniform resource locator are automatically generated by the first application. The method where the uniform resource locator represents a mapping of a context associated with a user requesting the launch of the second application to a plurality of parameters in the second application. The method further including, generating an updated uniform resource locator that includes default parameters based on the mapping of the context, in response to determining that the user interface platform is a platform other than HTML5 and generating the second application in an inline frame using the updated uniform resource locator. The method where the plurality of parameter values represent default values configured for a user requesting the launch of the first application or the second application. The method where the plurality of parameter values are predefined by a user in a third application for configuring settings. The method where the plurality of parameter values are automatically derived based on a role of a user associated with at least one application provided by at least one user interface platform. The method where the plurality of applications are configured to execute on a plurality of the multiple user interface platforms in parallel to provide the same user interface functionality using the plurality of parameter values. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is an illustration of a user interface entry point (a viewport) for a particular user experience.

FIG. 1B is an illustration showing an example login screen displayed in a shell main container.

FIG. 1C is an illustration showing an example launchpad displayed in a shell main container.

FIG. 1D is an illustration showing an example active application screen (an overview page) displayed in a shell main container.

FIG. 1E is an illustration showing an example object page displayed in a shell main container.

FIG. 1F is an illustration showing an example footer toolbar.

FIG. 1G is an illustration showing an example me area that can be displayed in a left container.

FIG. 1H is an illustration showing an example notification area that can be displayed in a right container.

FIG. 1I is an illustration showing an example copilot user interface.

FIG. 1J is an illustration of a timeline user interface that can display timeline entries.

FIG. 2 is a diagram of an example system that can implement the user interfaces and user experiences described herein.

FIG. 3 is a block diagram showing an example of parameter passing in the architecture described herein.

FIG. 4 is a block diagram showing an example call sequence for target and parameter mapping.

FIG. 5 is an example screenshot of an example settings UI.

FIG. 6 is a flowchart that illustrates a method for populating and transferring parameters across a plurality of applications executable on multiple user interface platforms

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

In order to improve a user experience (UX), a number of user interfaces can be implemented to intuitively propose relative context or intent to a user. Such intuitive context or intent may used to determine and/or derive initial and/or default data (e.g., parameters) and provide such parameters in one or more of the user interfaces. The user interfaces can use the parameters to conform to, recognize, and facilitate ways in which a user may personally work. The use of such a “smart” user interface (UI) and parameters can help a user easily manage and keep track of the context of current tasks and activities when carrying out transactional tasks.

In some cases, a grid matrix-style home screen or dashboard-like (UI) may be implemented as a “smart” interface to allow a user to open and access a selected application. In some cases, the grid matrix-style home screen or dashboard-like user interface allows a user to access content within an application. The content provided in such a user interface may be auto-populated and can include any number of parameters and values for the parameters.

In general, the user interfaces can prevent user experience (UX) and user interface (UI) shortcomings while attempting to provide optimized usability and user-centric business functionalities related to transactional tasks. The present disclosure describes an example architecture for providing such a user experience (UX). In particular, the architecture described herein can provide a number of parameters (and associated values for the parameters) that can be used to define default and/or initial information usable with applications hosted by the architecture. In one example, parameter values may refer to business data in a customer system. The parameter values may be defined by the user (e.g., customer) or accessed from another configuration source. In one example, the architecture can enable the applications to prefill default data using preconfigured parameters (and values). In some implementations, the architecture can enable the applications to derive default parameters (and values) to populate data in fields of a user interface provided by the architecture.

The parameters described throughout this disclosure may refer to default or initial parameters that provide a value for a particular user interface hosted by the architecture described herein. The values may be user-specific or environment specific. In some implementations, the parameters and values may be role-based. In some implementations, the values may be derived for each parameter from different sources (e.g., default values defined by the user). In some implementations, the architecture described herein may provide a central (e.g., settings) user interface in which the user can access to define default values for the parameters. In general, the parameters and values may be relevant across any number of applications. In some implementations, the parameters can also be used (and passed) across differing user interface technologies.

In operation, the architecture described herein can enable transactional applications, analytical applications, and contextual navigation-based applications to be integrated. For example, a transactional application may provide access to tasks such as change, create, or processes with guided navigation. The transactional applications may be deployed by the architecture as one or more UI add-ons and the applications may be connected via a service (e.g., Open Data Protocol (OData) service via a uniform resource identifier (URI)).

The architecture can additionally provide analytical applications that provide a visual overview of a complex topic for monitoring and/or tracking purposes. Context/navigation-based applications can include search and explore options that provide a view on information about an object in the UI and can provide contextual navigation between related objects in the UI (or background of the UI). Analytical applications can be connected via services (e.g., OData services). In addition, analytical applications may use virtual data models.

In general, enterprise transactional applications can evolve from large monolithic on-premise software deployments into multiple (e.g., hundreds of, thousands of) small, componentized applications that can execute (run) on various types of computing devices and network platforms. For example, the fifth version of Hypertext Markup Language (HTML5) can be used as a basis for structuring and presenting an application platform that includes a grid matrix-style home screen or dashboard-like user interface. The use of HTML5 can provide an improved user experience, can reduce a user interface complexity, and may increase user productivity across multiple types of computing devices. The computing devices can include, but are not limited to, desktop computers and mobile computing devices such as laptop computers, tablet computers, notebook computers, personal digital assistants (PDAs), smartphones, mobile phones, smart watches, etc.).

For example, users may need to navigate back and forth between multiple screens that can include home screens, application instances, and drill downs, in order to perform various transactional tasks to make viable business decisions. The user may need to navigate back and forth between multiple screens when viewing related data between various applications.

For example, applications and application instances may not interoperate with each other. Because of this, user navigation and operations may not be minimized. Applications may not readily access relative content without first needing to open an application instance and then perform numerous navigations.

A shortcoming of a UX and a UI can be a lack of relative business contexts related to user roles and expertise that can empower employees to do their job better, faster, and in a more deliberate way. Providing a user with a way to personalize an experience of the user based on a role requirement of the user can result in a better overall user experience. For example, the personalization can result in a UI automatically providing proposals for transactional tasks that the user may need to see. The proposals can be provided at a time when the user wants to see the proposal and on a computing device chosen by the user. The proposals can be provided to the user as a result of a single click or gesture input to the user interface by the user. The UI can be considered a central interface that can provide a user with the ability to communicate, collaborate, initiate, and/or respond to colleagues, managers, and customers without leaving the context of their current activity or application.

Alternatively, a user may have to navigate through multiple applications and user interfaces. A user may easily lose a context of a current task or activity while having to navigate through user interfaces provided in a multiple application environment for an enterprise. The loss of context can affect the ability of the user to effectively carryout a transactional task. In addition, navigating through user interfaces provided in a multiple application environment may not allow a user to readily view, at a glance, live data that may be relevant to personal and professional daily activities, responsibilities, and organizational accountabilities of the user. The user may not be provided with a way to efficiently manage hundreds (or thousands) of applications associated with transactional workflows in the enterprise.

Enterprise applications that are associated with transactional workflows in an enterprise can be implemented using a software development technology or foundation (e.g., HTML5/CSS/JS technology) in a particular UI framework (e.g., HTML5) in order to provide a beneficial UX and UI. The enterprise applications can be implemented to execute or run on multiple different types of computing devices such as desktop computers and mobile computing devices (e.g., laptop computers, tablet computers, notebook computers, personal digital assistants (PDAs), smartphones, mobile phones, smart watches, etc.).

For example, the UI may use elements of a particular UX (e.g., an SAP Fiori® UX) to provide a user with a personalized, responsive, seamless, and simple user experience across enterprise applications (including legacy and new), across different types of computing devices such as desktop computers and mobile computing devices (e.g., laptop computers, tablet computers, notebook computers, personal digital assistants (PDAs), smartphones, mobile phones, smart watches, etc.), and across all possible deployment options (e.g., on-premise, cloud, as-a-service, etc.).

The particular UX can deploy an array of interactive features and process tools that can be integrated with a suite or set of enterprise applications that have specific functionalities. The particular UX can provide intelligent, contextual-based support for users across an enterprise. The particular UX can use a “push” model that can anticipate tasks (e.g., transactional tasks) for a user based on a role of the user in the enterprise. The particular UX can import real-time data that can be tailored to specific tasks. The software for the UI for the particular UX can be implemented to easily and transparently scale the UI accordingly for display on each display device included in each of the different possible computing devices that can execute (run) the enterprise applications.

FIG. 1A is an illustration of a UI entry point (a viewport 100) for a particular UX. The viewport 100 can be a single-screen view partitioned into multiple (e.g., three) multifunctional screen areas (e.g., a left screen area (left container 102, a center screen area (shell main container 104), and a right screen area (right container 106) for display in a display area (on a display device) included in a computing device. The viewport 100 can include a shell toolbar 108. The shell toolbar 108 can include a global search and other services, which are available to a user across all enterprise applications.

The shell main container 104 can display information for use as a main workspace for the UX. In some implementations, multiple different screens can be displayed in the shell main container 104. For example, a login screen, a launchpad screen, and an overview page can alternatively be displayed in the shell main container 104. The viewport 100 can provide a user with a screen orientation that can allow the user access to application information. The viewport 100 can provide the user with a UX and UI the includes the business functionalities and enterprise application-to-application navigations needed by the user without disrupting a context of a current task of the user.

FIG. 1B is an illustration showing an example login screen 110 displayed in the shell main container 104. The login screen 110 provides a UI that allows a user to enter credentials in order to log into and begin a personalized and customized UX. In the example shown in FIG. 1B, the login screen 110 appears to drop into the shell main container 104 from a virtual extension area located along a top of a display area. In some implementations, the virtual extension area can be placed along the bottom of the display area. In some implementations, the virtual extension area can be placed to the left and/or the right of the display area.

FIG. 1C is an illustration showing an example launchpad 112 displayed in the shell main container 104. The launchpad 112 can be a web-based entry point (or homepage) for enterprise applications that can execute (run) across multiple platforms and computing devices. In the example shown in FIG. 1C, the launchpad 112 appears to drop into the shell main container 104 from the top of a display area. In some implementations, the virtual extension area can be placed along the bottom of the display area. In some implementations, the virtual extension area can be placed to the left and/or the right of the display area.

The launchpad 112 can serve as a bracket around (or a base for) a set (or group) of enterprise applications, providing a single point of entry for the set of enterprise applications. In the example shown in FIG. 1C, the launchpad 112 presents (displays on a screen of a computing device of a user) each application represented by a tile. A tile can be a container that represents the application. Each tile can display different types of content. A user can interact with each tile to navigate to the specific enterprise application associated with the tile. In addition, when designing a tile to represent a specific application, a programmer can assign a tile to a specific user or group of users. The launchpad 112 can provide one or more services. The one or more services can include, but are not limited to, application-to-application navigation, personalization, role-based application assignments, search, and incident creation.

The launchpad 112 can be a role based, personalized, real-time and contextual aggregation point for business applications and analytics. The launchpad 112 can run (execute) on multiple computing devices including, but not limited to, desktop computers and mobile computing devices such as laptop computers, tablet computers, notebook computers, personal digital assistants (PDAs), smartphones, mobile phones, smart watches, etc.). In addition, the launchpad 112 can be deployed on multiple platforms (e.g., Linux, Windows, Windows Phone, MAC®, iOS®, OS X®, Android®, etc.).

The launchpad 112 includes tiles 114a-h. Each tile can display different types of content. For example, tile 114a can be a news and feeds tile that can enhance collaboration by providing a user with information about the enterprise. The tiles 114a-h can be individually color-coded. A color can represent a particular role (e.g., finance, human resources, supply chain management (SCM), customer relationship management (CRM), etc.). The tiles 114a-h can be associated with a group 116. Tile 114f can be a key performance indicator (KPI) tile. Tile 114b can be a basic launch tile. Tile 114d can be a monitoring tile. Tile 114g can display a comparison chart for specific content.

The launchpad 112 includes a link list area 118 that includes links 119a-f. The link list area 118 is an area on the launchpad 112 that can provide links to enterprise applications represented by the tiles 114a-h. For example, a user can select and drag a tile from the tile area on the launchpad 112 into the link list area 118 to create a link to the application associated with (represented by) the tile. In some implementations, the launchpad 112 can include a footer toolbar (e.g., footer toolbar 132 as shown in FIG. 1F). In some implementations, the footer toolbar can appear to float over the content displayed in the launchpad 112.

In some implementations, the shell toolbar 108 can display a search icon 111 and a copilot launch icon 113. A user can select (click on) the copilot launch icon 113 to launch a copilot UI. A copilot UI will be described in more detail with reference to FIG. 1I.

FIG. 1D is an illustration showing an example active application screen (overview page 120) displayed in the shell main container 104. The enterprise applications that can be accessed by a user by way of the launchpad 112 and then subsequently displayed in an active application screen (e.g., the overview page 120) can include, but are not limited to, transactional applications, analytical applications, and fact sheet applications (contextual navigation applications). Transactional applications can allow a user to create, change and/or approve processes with guided navigation. Analytical applications can provide a user with a visual overview of a dedicated topic for monitoring and tracking purposes to allow for further key performance indicator (KPI) related analysis. Fact sheet applications can allow a user to view essential information about an object and to allow navigation between related objects.

The overview page 120 can visualize all of the information a user may need for a specific business context (business domain) on a single page or screen. The information can be displayed in one or more variable content packages (VCPs) or cards 122a-i. Each card can be a container of content for organizing large amounts of information on an equal plane within the overview page 120. In some implementations, a user can rearrange the position of the cards 122a-i on the overview page 120. In some implementations, a user defines, adds, or deletes cards included in the overview page 120.

An overview page (e.g., the overview page 120) can be a selectable application (e.g., from the launchpad 112) providing an integrated gateway into enterprise applications and application content included in the launchpad 112. The UI of the overview page (e.g., the overview page 120) can provide a user with a visual summary of data, links, actions, and content that are relevant to a business domain of expertise of a user and relevant to a selected role of the user within the domain. The visual summary can be presented in one or more cards (e.g., the cards 122a-i) that display live content to a user at-a-glance without the user having to open multiple applications and perform multiple drill downs through application content to find and present the content.

In some implementations, the overview page 120 can include a footer toolbar (e.g., footer toolbar 132 as shown in FIG. 1F). In some implementations, the footer toolbar can appear to float over the content displayed in the overview page 120.

In some implementations, an enterprise system can determine content displayed on an overview page (e.g., the overview page 120). In addition or in the alternative, a selection of one or more business domains and one or more roles of a user in the business or enterprise can determine content displayed on an overview page (e.g., the overview page 120). In some implementations, a user can make the selection using a settings UI included in a launchpad (e.g., the launchpad 112). In some implementations, a user can select one or more business domains and/or one or more roles of the user in the enterprise by way of an overview page (e.g., the overview page 120). Selecting one or more business domains and/or one or more roles of the user in the enterprise by way of the overview page can maintain absolute relevance to the individual user and the way in which the user works.

In some implementations, the user can personalize the layout and placement of one or more cards (e.g., the cards 122a-i) included in a UI of an overview page (e.g., the overview page 120) and the display of content included in each card. The personalization can enhance the workplace productivity of the user.

FIG. 1E is an illustration showing an example object page (object page 124) displayed in the shell main container 104. An object page can be a floor-plan used to represent objects in a UI. An object page can be used to display, create, or edit an object. An object can represent a business entity (e.g., a customer, a sales order, a product, an account, etc.). Enterprise applications that reflect a specific scenario (e.g., a sales order, am account status) can be bundled using an object. The object page can include a header area 126, a navigation area 128, a content area 130, and, in some implementations, a footer toolbar (e.g., footer toolbar 132 as shown in FIG. 1F). In some implementations, the footer toolbar can appear to float over the content displayed in the object page 124. For example, referring to FIG. 1C, a user can select the tile 114f and an object page can be displayed to the user.

FIG. 1F is an illustration showing an example a footer toolbar (e.g., footer toolbar 132). In some implementations, referring to FIG. 1A, the footer toolbar 132 can appear at the bottom of a screen displayed in the shell main container 104, the left container 102, and/or the right container 106. For example, as described herein with reference to FIGS. 1C-E, a footer toolbar (e.g., the footer toolbar 132) can be displayed at the bottom of the launchpad 112, the overview page 120, and the object page 124. The footer toolbar (e.g., the footer toolbar 132) can continue to appear at the bottom of the screen of the display area of the display device even as the displayed screen is scrolled. The footer toolbar (e.g., the footer toolbar 132) can appear to hover over or float over the content being displayed on the screen. The footer toolbar 132 can include buttons or controls 134a-k. The controls 134a-k can be selected by a user in order to perform one or more actions that can impact content included on the page being displayed on the screen. The controls 134a-k are examples of controls that can be included in a footer toolbar. In some implementations, the controls can be different, fewer than, or more than the controls 134a-k. The type and number of controls included in a footer toolbar can be based on the type of page being displayed and/or the content being displayed in the page.

FIG. 1G is an illustration showing an example me area (e.g., me area 136) that can be displayed in the left container 102. In some implementations, the me area 136 can be displayed in the right container 106. The me area 136 includes an upper section 138 and a lower section 140. The upper section 138 includes a user icon 142. Selecting (clicking on) the user icon 142 can provide a user profile. A dropdown indicator button 144 displays a status of the user and, if selected, a user can logout of an application. The upper section 138 includes navigation targets 146a-e. Selection of (clicking on) a navigation target by a user triggers a corresponding functionality (e.g., an application) associated with a navigation target. The me area 136 can provide various generalized functionalities as they are related to a user.

The upper section 138 can include sort selections 146a-b. A user can select (click on) a sort selection (e.g., one of the sort selections 146a-b) to determine how the listing of the recent activities included in the lower section 140 will be sorted and displayed.

The lower section 140 of the me area 136 includes a list of recent activities 148a-c. The recent activities 148a-c can include links 156a-c, respectively, that when selected (clicked on) by a user can navigate the user to back to the shell main container 104, opening an application (or function) that corresponds to the link in the shell main container 104. Recent activity items can include, but are not limited to, enterprise applications, triggered searches, co-pilot collections, and co-pilot drafts.

FIG. 1H is an illustration showing an example notification area (e.g., notification area 150) that can be displayed in the right container 106. In some implementations, the notification area 150 can be displayed in the left container 102. The notification area 150 includes notifications 152a-c. A user interacting with the UI in the notification area 150 can take immediate action on a notification. A notification item (e.g., notifications 152a-c) can have an indicator (e.g., notification indicators 154a-c) that can indicate the status of the notification. For example, a notification indicator can be color coded to indicate a particular status of the notification.

A user can reject a notification by selecting (clicking on) a reject selection (e.g., a reject selection 156a-b). For example, a user can reject the notification 152a by selecting (clicking on) the reject selection 156a. The rejection of the notification 152a (the notification status) can be indicated by content included in (e.g., a color of) a notification indicator 154a. A user can acknowledge a notification by selecting (clicking on) an acknowledge selection (e.g., a acknowledge selection 158a-b). For example, a user can acknowledge the notification 152b by selecting (clicking on) the acknowledge selection 158b. The acknowledgement of the notification 152b (the notification status) can be indicated by content included in (e.g., a color of) a notification indicator 154b.

A user can drill down into a relevant application by selecting (clicking on) a more info selection (e.g., a more info selection 160a-b). In some cases, a user may contact someone directly in response to a notification.

FIG. 1I is an illustration showing an example copilot UI (e.g., copilot UI 162). For example, referring to FIG. 1C, a copilot application can be launched from the launchpad 112 when a user selects (clicks on) the copilot launch icon 113. The copilot application can provide (generate and display) the copilot UI 162. In some cases, the copilot UI 162 can float over the UI included in the launchpad 112. As a floating UI control, the copilot UI 162 can be visually unobtrusive and flexible in its cross-functional omnipresent implementation across any device or application screen.

The example copilot UI 162 is an example copilot start page or start screen. The start screen (the copilot UI 162) can be an entry point for copilot functionality for an enterprise system.

The copilot UI 162 can provide shortcuts to different copilot features. For example, as shown in FIG. 1I, a collection can be represented by an entry in a collection list 164 that includes collection list entries 164a-d. A copilot collection can be a cluster of items in relation to a specific topic. For example, an item can be a note, a screenshot, a chat message, a copilot message, an object, or a quick create. In some implementations, the items included in the collection can be homogeneous (e.g., all of the items are of the same type). In some implementations, the items included in a collection can be non-homogeneous (e.g., the items can be of different types). Each collection list entry 164a-d can provide a representation of a collection that can include a title, a timestamp (e.g., last changed), a visual content summary, and a textual content preview. In some implementations, the collection list 164 can be searched and/or filtered.

For example, the selection of a copilot shortcut 166a-d can allow a user to create and navigate to a new collection with a specified intention. The selection of a copilot create icon 168 located in a copilot footer toolbar 170 can create and navigate to a new plain collection. The selection of a copilot settings icon 172 located in the copilot footer toolbar 170 can allow a user access to copilot settings (e.g., display a copilot settings UI, open a copilot settings application, etc.).

Copilot entries can be living, gradually growing artifacts and software entities that can accompany a user from the identification of an issue to a solution for the issue, while providing support in the form of relevant context and actions. Copilot entries can serve as memory aides while the copilot entries can incrementally evolve into valuable transactional tasks and collaborations as they mature in meaningful ways that bridge a gap between predefined application functionality and processes based on personal ways of working for a user. Though the example shown in FIG. 1I describes launching the copilot application from the launchpad 112, referring to FIG. 1A, the copilot application can be launched from other screens displayed in (included in) the shell main container 104, the left container 102, and/or the right container 106.

Copilot entries can be made ready for users to use when communicating, collaborating, and creating actionable transactions in desktop or mobile scenarios. For example, copilot text entries can be analyzed for recognizing and identifying relevant text related objects. Copilot text entries can emphasize displayed text, and a copilot application can recommend contextual entities for use in a current task. The copilot application can understand user context and can intelligently propose selections, auto-entries, and user options.

A smart template can provide a framework for generating user interfaces at runtime for an enterprise application. For example, a smart template can be used to generate the UI for the overview page 120 as shown in FIG. 1D. In another example, a smart template can be used to generate the UI for the object page 124, as shown in FIG. 1E. A smart template can provide a framework for generating the user interfaces based on metadata annotations and predefined templates for the most used application patterns. The use of smart templates can ensure design consistency by providing centralized high quality code by using predefined templates and controllers. The use of smart templates can keep applications up to date with evolving design guidelines. The use of smart templates can reduce an amount of front-end code used in building enterprise applications. The term “smart” can refer to annotations that add semantics and structures to provided data. The term “smart” can also refer to the way in which the templates understand the semantics.

FIG. 1J is an illustration of a timeline UI (e.g., the timeline 174). A timeline UI (e.g., the timeline 174) can display timeline entries 176a-e. For example, the entries can be events, objects, and/or posts listed and displayed in a chronological order. The timeline 174 includes nodes 178a-d that correspond to respective timeline entries 176a-d.

The timeline 174 can be used for collaborative communications. The timeline 174 can be configured in multiple different ways depending on use case implementations. For example, the timeline 174 can provide information about changes of an object or about events related to an object. The timeline 174 can provide information about generated entries (e.g., value XY changed from A to B) or about manual entries (e.g., comments from an individual). In some implementations, the latest entry is at the top of a list displayed by a timeline. In some implementations, the timeline 174 can be displayed along with a business object. In some cases, the timeline 174 can be displayed to the right of the business object.

Two example versions of a timeline can include a basic timeline and a social timeline. A basic timeline can be a read-only timeline. A social timeline can allow for interaction and collaboration among users.

FIG. 2 is a diagram of an example system 200 that can implement the user interfaces and user experiences described herein. The system 200 includes an enterprise computing system 202, a network 204, and client computing devices 206a-e.

For example, computing device 206a can be a mobile phone, a smartphone, a personal digital assistant, or other type of mobile computing device. The computing device 206a includes a display device 220. For example, computing device 206b can be a laptop or notebook computer. The computing device 206b includes a display device 222. For example, computing device 206c can be a tablet computer. The computing device 206c includes a display device 224. For example, the computing device 206d can be a wearable device such as a smartwatch. The computing device 206d includes a display device 226. For example, the computing device 206e can be a desktop computer. The computing device 206e can include a display device 228. A user of the computing devices 206a-e can use/interface with the display devices 220, 222, 224, 226, and 228, respectively, when interacting with the enterprise computing system 202. The computing devices 206a-e can display on the display devices 220, 222, 224, 226, and 228 any of the screens and UIs described herein.

The enterprise computing system 202 can include one or more computing devices such as a web management server 214, a frontend server 230, a backend server 208, and a mobile device management server 210. The enterprise computing system 202 can also include a database management computing system 212 that includes a database management server 212a and a database 212b. Though not specifically shown in FIG. 2, each server (the web management server 214, the frontend server 230, the backend server 208, the mobile device management server 210, and the database management server 212a) can include one or more processors and one or more memory devices. Each server can run (execute) a server operating system.

In some first implementations, the client computing devices 206a-d (e.g., the mobile computing devices) can communicate with the enterprise computing system 202 (and the enterprise computing system 202 can communicate with the client computing devices 206a-d) by way of the mobile device management server 210. The mobile device management server 210 includes one or more mobile device platform application(s) 216. By using the mobile device platform application(s) 216, the enterprise computing system 202 can deliver cross-platform, secure, and scalable applications to the computing devices 202a-d, independent of the mobile computing device-type (e.g., laptop, notebook, smartwatch, mobile phone, PDA, etc.) and independent of the operating system running on the computing device 206a-d. In these implementations, the mobile device management server 210 can then communicate with the web management server 214.

In some second implementations, the client computing devices 206a-e (both the mobile computing devices (computing devices 206a-d) and the desktop computing device 206e) can communicate with the enterprise computing system 202 (and specifically with the web management server 214), and the enterprise computing system 202 (and specifically with the web management server 214) can communicate with each of the client computing devices 202a-e) using the network 204. The web management server 214 includes a web dispatcher application 218. In both the first implementations and the second implementations, the web dispatcher application 218 can act as a “software web switch” accepting or rejecting connections to the enterprise computing system 202.

In some implementations, the network 204 can be a public communications network (e.g., the Internet, cellular data network, dialup modems over a telephone network) or a private communications network (e.g., private LAN, leased lines). In some implementations, the computing devices 206a-e can communicate with the network 204 using one or more high-speed wired and/or wireless communications protocols (e.g., 802.11 variations, WiFi, Bluetooth, Transmission Control Protocol/Internet Protocol (TCP/IP), Ethernet, IEEE 802.3, etc.).

The frontend server 230 can include product specific UI Add-On Applications 232 and a UI infrastructure 234. The UI infrastructure 234 can include a design portion and a runtime portion. The frontend server 230 can decouple a lifecycle of a UI (e.g., design and runtime deployment) from the backend server 208. The decoupling can allow UI applications to interface with a plurality of different databases. The decoupling provides a single point of UI design, access, and maintenance allowing for theming, branding, configuring, and personalizing a UI without a need for development privileges to the backend server 208 (e.g., no need to have backend administrative rights). The decoupling can result in a more secure enterprise computing system. The decoupling can provide for rule-based dispatching of requests in a multi-system landscape (e.g., for approvals including aggregation).

In some implementations, the frontend server 230 includes a settings user interface (UI) 235 configured to receive input from users. The input may pertain to default values. In some implementations, the frontend server 230 can include a number of user configured or system-derived parameters 237. Such parameters may be initial or default values for fields displayable to a user in UIs. In some implementations, the frontend server 230 can receive or retrieve user settings using a user settings service 241

Applications may map the new parameters to existing SET/GET-parameters in case of ABAP backend systems. Launchpad functionality can provide the user settings service 241, which provides an interface for client-side plug-ins. The plugins are implemented by applications. For each parameter, there may be an implementation in one plug-in. The plug-in implementation may provide user-specific parameter values as well as data used by the parameter settings UI (i.e., language dependent texts and value help). To gather such information, plug-ins may connect via the Gateway System to an application specific User Settings Service (e.g., OData) in the backend system. The OData Service implementation may get values from corresponding SET/GET parameters (in case of an ABAP backend system), derive the value from organizational structures or use any other User Context Persistency as a source. Plug-ins and corresponding OData Services may also be implemented by non-ABAP based cloud applications. The user based launchpad service may call the plug-in implementations at target resolution or before an application is started if parameter values are requested and no value is available from another source. It may distinguish storable and not-storable parameters (information provided by the plug-in implementation). Values of storable parameters are persisted on the Frontend server in a user context persistency. This makes it possible to transport all persisted parameters of the current user to the client when the user based launchpad is started and cache the data in the resource cache in a browser. This can provide an advantage of avoiding subsequent backend requests and achieve optimal performance.

The settings UI 235 may be accessed by end-users to check and modify their default values for (storable) application parameters. The service 241 may determine the parameters listed in this UI from applications available to the current user based on his role assignment. Language dependent texts, field lengths, format information, and value helps may be provided by the plug-in implementations.

User context 243 may represent a user intent, which can be used for intent-based navigation. An intent (e.g., context) is composed from a semantic object and an action and a set of name value pairs (“intent parameters”) to be executed. In one example, the architecture launchpad is called with a URL containing the intent (e.g., context) and possibly additional parameters and its task is to resolve and star a target application. The string may be represented in a fragment part of the URL

The frontend server 230 includes a gateway 236. The gateway 236 can provide a way to connect devices, environments, and platforms to enterprise software based on market standards. The gateway 236 can enable the development of UIs for use in different environments (e.g., social and collaboration environments). The gateway 236 can enable the development of UIs for use on different types of client computing devices (e.g., client computing devices 206a-e). The gateway 236 can enable the development of UIs for use in internet-based applications.

The backend server 208 can include a bundle (a set) of business applications (e.g., business suite 238). The business applications can be transactional applications. Analytical applications, and fact sheet and contextual navigation applications. Transactional applications can allow task-based access to tasks that can include create and change. In addition or in the alternative, transactional applications can allow access to entire processes with guided navigation. Analytical applications can provide a user with a visual overview of complex tasks for monitoring and tracking purposes. Fact sheet applications and contextual navigation applications involve search and explore activities. Fact sheet applications and contextual navigation can allow a user to view essential information about an object and can allow contextual navigation between related objects.

The database management computing system 212 includes a database management server 212a that can run (execute) applications that can manage a database 212b. For example, the database 212b can be an in-memory, column-oriented, relational database (e.g., SAP HANA®). The database management computing system 212 can include extended application services 240 that can embed a full featured application server, web server, and development environment within the database management computing system 212. The extended application services 240 can include application content 242 and reuse content 244 for use by the enterprise computing system 202 when providing a personalized, responsive, and simple UX across different types of computing devices and deployment options.

The application services 240 may also provide applications 246 and descriptors 248. The application 246 may include an application identifier and an application version. The application 246 may be any type of application that is configured to be deployed to and operate on a computing device, where the computing device includes at least one memory and at least one processor (a microprocessor, a hardware processor, etc.) such that the processor executes the application code (or instructions) that instructs the processor to implement the application 246.

The application 246 includes a web application, which may include user interface applications, content access application, collaborative applications, enterprise applications, and any other type of application. The web application may be deployable on any type of computing device and capable of being run using a browser application on the computing device. The web application also may be a standalone application that runs within an operating system. The web application may be designed to enable end users to accomplish one or more tasks. However, the web application is not limited to end user type applications and may include other types of web applications that may run in the background in an operating system environment or a browser environment without interfacing with an end user.

The application 246 may be perceived as an entity, even if it is content and services are distributed over different system landscapes and different repositories. The application identifier uniquely identifies the application 246. In some implementations, the application identifier includes a unique uniform resource locator (URL). The application identifier enables the application to be uniquely identified and matched with other components and resources using the unique identifier. Additionally, the URL may be presented to an end user as part of a user interface (UI) for selection and launch of the application 246 in various different platforms.

The application descriptor 248 includes a single file that is packaged and delivered to a platform along with the application 246. The descriptor 248 provides a central, machine-readable and easy-to-access location for storing metadata associated with the application 246. The data within the descriptor 248 may be structured and formatted in an organized manner. In one example implementation, the data is stored in JavaScript Object Notation (JSON) format and may be structured and organized using multiple namespaces such as Namespace A and Namespace B. In this manner, a single descriptor 248 may enable the application 246 to be deployed and operated on different platforms using different namespaces.

The descriptor 248 includes multiple namespaces. For example, the descriptor 248 may include a Namespace A and a Namespace B. The descriptor 248 is extensible to enable the addition of other namespaces as well after creation of the initial namespaces. Examples of namespaces with in the descriptor 248 include an application namespace and platform-specific namespaces. For instance, the namespaces may include the SAP.APP namespace, the SAP.UI namespace and the SAP.UI5 namespace. Other namespaces may include the Fiori namespace and other platform-specific namespaces.

Each of the namespaces include application-specific attributes. The application-specific attributes define parameters and include values used by the application 246 for a particular namespace. The application-specific attributes may include both mandatory and optional attributes. Mandatory attributes include attributes that may be needed to enable the application to run with in a particular namespace. Optional attributes include attributes that are not necessary to enable the application to run but may be desirable and/or may be needed to enable the application to operate within a particular namespace. Having all the possible namespaces in one descriptor 248 enables the application 246 to be deployed on multiple different platforms using different namespaces. Examples of namespaces and their application-specific attributes are described in the tables in more detail below.

The application 246 packaged with its corresponding descriptor 248 may be deployed and installed on many different types of platforms. The descriptor 248 is platform agnostic meaning that the descriptor 248 may be implemented and used on different platforms without making changes to the descriptor 248 to enable its execution on the different platforms. At the same time, the descriptor 248 includes platform-specific information with in the various namespaces and the application-specific attributes contained within each namespace. In this manner, the descriptor 248 is a universal-type document because of the flexibility and technical advantages provided to deploying, installing and operating an application 246 on the various different platforms.

The application 246 and its corresponding descriptor 248 may initially be implemented on a single development platform. The development platform 120 may include a computing device or multiple computing devices on which the application 246 and the descriptor 248 are first developed in the first stage of the application lifecycle. The development platform 120 includes memory and processing resources to enable the interaction, development and creation and validation of the application 246.

The application 246 and its corresponding descriptor 248 also may be deployed on other platforms including a mobile platform, an SAP HANA Cloud platform and an Advanced Business Application Programming (ABAP) platform. Each of the different platforms may use one or more different namespaces and application-specific attributes for the particular namespace and platform. The descriptor 248 includes all of the information needed for the application 246 to run on each of the platforms and/or within different namespaces on different platforms.

The descriptor 248 may include a Fiori namespace that may operate on platforms that run on desktop computing devices, tablet computing devices, laptop computing devices, mobile computing devices such as smartphones, wearable devices such as smart watches, etc. The descriptor 248 is used in Fiori applications and in all of the lifecycle phases of a Fiori application. The descriptor 248 includes a Fiori namespace and application-specific attributes directly relevant for the Fiori namespace to run Fiori applications. In this manner, the single descriptor file 248 enables the application 246 to run as a Fiori application on different platforms that support Fiori applications, which may be on different types of computing devices.

The SAP HANA Cloud platform (or simply HANA Cloud Platform) may include a platform running within an application such as a browser application that renders applications using HTML5. The HANA Cloud platform includes its own namespace and application-specific attributes. The descriptor 248 may include an sap.platform.hcp namespace and application-specific attributes directly relevant for the sap.platform.hcp namespace. In this manner, the single descriptor file 248 enables the application 246 to run on a HANA Cloud platform, which also may be on different types of computing devices.

The ABAP platform may include a platform running on a computing device that uses programming specifically for this platform. The ABAP platform may use one or more different technologies including the SAP.UI technology, the SAP.APP technology and the SAP.UI5 technology. Each of these different technologies may include their own namespace and corresponding application-specific attributes. The descriptor 248 includes namespace is an application-specific attributes for each of these different technologies, which may be utilized by an ABAP platform. Other platforms may include different namespaces, where the descriptor 248 includes the namespace and application-specific attributes for the namespace to run on the other platforms.

In some implementations, the descriptor 248 may include a single portion that includes all of the code and configuration parameters needed by the application 246. The single portion may be created during a development lifecycle and added to throughout the other stages of the lifecycle of the application 246.

A number of parameters associated with the architecture (e.g., applications and application descriptors) described herein may be used with a UI to enable a user to begin work on a task or process, save incomplete work automatically, and continue to work on the task or process at a later time (and/or from another device). The data and session work is saved without issue of a timeout or connectivity disruption issue that can plague typical networked applications. In addition, the parameters can enable the architecture to save work from one user that can be accessed and completed by another user. In this way, the work product (e.g., tasks, processes, application content, messaging) can be associated with particular parameters defined by the architecture. Such work product may advantageously not be tied to a particular device, session, or user.

The parameters may define initial values (e.g., default data) associated with data and data fields in applications. For example, the parameters can automatically prefill (e.g., populate) particular UI fields. One example UI field that may be populated include selection parameters shown in list views, which may provide an ability to immediately execute a query. Another example UI field that may be automatically populated based on the parameters may include entry screens that provide an ability to skip the entry screen if particular fields are already filled (e.g., populated). The default data may include values that are user-specific for one or more parameters. In one example, parameter values may refer to data in a customer system. In some implementations, customers (e.g., users) can define default parameter values. In other implementations, the systems described herein can define default parameter values.

In operation, parameters (and associated values) can be provided to applications implemented within any number of different UI technologies (e.g., platforms) including, but not limited to HTML5 (e.g., SAP.UI5), WebDynPro, WebGUI, and SAPGUI). The values for the parameters can be derived from one or more different sources (e.g., default values defined by a user having a defined ranking). In some implementation, a central UI may be provided in which users can define default values for a number of parameters.

FIG. 3 is a block diagram 300 showing an example of parameter passing in the architecture described herein. In general, the architecture described in FIGS. 2 and 3 can be executed in a browser, a native application, a plug-in, a mobile app (e.g., packaged or standalone), an offline application, and/or additional platforms operable to receive a service. In general, the architecture described in FIGS. 2 and 3 can be executed without installation on a computing device.

In an example enterprise resource architecture, a number of parameter identifiers (e.g., SET-parameters/GET-parameters values) may represent development objects owned and delivered by respective application components. The SET/GET parameters may be stored in a database table. In one example, a user settings UI 235 can be used to enter parameters and values. In such an example, a static value can be entered for a parameter value.

As shown at block 302, the user parameters can be stored with values. These values may be loaded into memory, as shown by block 304, when a user logs on to the system. In some implementations, parameters can also be controlled in frontend server 230 (e.g., ABAP) programs with ABAP statements SET/GET PARAMETER. In some implementations, the value stored for the parameter in memory has the lifetime of to particular logon session and thus, may not be available when the user logs off and on again. It may be possible to store static values for parameters in the frontend server 230 user maintenance area. Such values are loaded into memory when a user logs on to the system and are then available as default when the user opens a screen with a parameter for the first time.

Parameters can be passed in navigation between applications. For example, if a particular application transaction is called via SAPGUI, relevant parameters can be passed between screens (e.g. from block 306 to block 308), between transactions, and between SAPGUI modes (e.g., windows) via the memory shown at block 304.

This feature is based on parameter values, which can be assigned to particular data elements in a data dictionary (e.g., DDIC) at block 310. In a screen, attribute developers can define whether a particular SET/GET parameter is active for a UI-field 312 with a parameter identifier 310b and value assigned. If a SET parameter is active, the system may automatically store a value in memory for the parameter 310a, which is previously entered by a user in the UI field. If a GET parameter is active and the value of the UI field 312 is initial at runtime, the system automatically attempts to read a value for the parameter identifier from memory and sets the value into the UI field 312 instead of an initial value. Thus, it is possible to provide a value entered by the user in a field 312 with a specific semantic in one screen that is also a suggested value for a field 314 with the same semantics in a subsequent screen after navigation to the subsequent screen. This may function across many navigation steps and across different applications.

If particular application transactions are called with the WebGUI platform, the memory and the SET/GET parameter mechanism shown in FIG. 3 may be available. However, the WebGUI platform may support only one mode (e.g., browser window/tab) per logon session. It may not be possible to pass parameters across browser windows or tabs via the memory using the WebGUI platform. Further, if a WebGUI application (e.g., transaction) is embedded in a host application (e.g. Portal or launchpad), WebGUI may close and open a new session when the user navigates from one WebGUI application (e.g., transaction) to another application. Here, it also may not be possible to pass parameters across WebGUI applications via the memory.

To pass parameters across embedded WebGUI applications, the hosting application has to hand over values as uniform resource locator (URL) parameters. WebGUI supports to add parameters to the URL with the technical name (e.g., used for Batch Input) of UI fields on the first screen. These UI field URL parameters do not typically correspond to SET/GET parameters (i.e., only if a UI field has a parameter assigned the value of 1).

If an application is called via the WebDynpro platform, applications may employ the same restrictions as mentioned above for the WebGUI platforms. It may not be possible to pass parameters across WebDynpro applications embedded in a hosting application via memory. Parameters may instead be handed over as URL parameters by the hosting application.

In general, WebDynpro applications provide interface parameters with technical names. For these interface parameters, values can be passed in the URL. The WebDynpro interface parameters are not related to SET/GET parameters and there is no automated way to store the values in memory for a parameter. Instead, the application implementation may match interface parameters with parameter identifiers and store values in the memory using SET/GET statements using the frontend server 230, for example.

In general, for HTML5 (e.g., SAP.UI5/FIORI) parameter navigation, a number of initial (e.g., default) parameters may function as intent parameters for Launchpad, as described above. The parameters may be enriched by further default information defined in a signature portion of a descriptor (e.g., mapping) for applications. The intent parameters are typically reflected in the URL, while further additions input by the architecture may be directly passed to the application component. Example code portions are shown below for an intent parameter, a Launchpad URL, and a matching signature.

Intent:

#SO-act?P1=V1Act
Launchpad URL:
. . . FioriLaunchpad.html#SOact?P1=V1Act)
Matching signature:
semanticObject: “SO”, “action”: “act”, “signature:” {
[name: “P1”, defaultValue: {“V1Def”}],
[name: “P2”, defaultValue: {“V2Def”}]}
Resulting actual startup parameters of the application:
P1=V1Act&P2=V2Def

The intent parameters values may be provided by a starting application or in a tile configuration. After identification of the appropriate matching signature (e.g., process of “navigation target resolution”), the initial (e.g., default) parameters of the application may be determined. The architecture may instantiate a UI5 component to pass the actual initial parameters as part of the UI5 componentData JavaScript object, for example. In a similar manner, for WebGUI platforms or WebDynpro platforms for frontend server 230, the started URL may contain the actual initial parameters as URL parameters.

In some implementations, the architecture described herein uses intent-based navigation paradigm. An intent is composed from a semantic object and an action and a set of name value pairs (“intent parameters”) to be executed. In one example the architecture launchpad is called with a URL containing the intent and possibly additional parameters and its task is to resolve and start the target application. The string is represented in the fragment part of the URL.

One example may include an intent/parameter for price condition (e.g., “PriceCondition-setSalesPricesMaterial s?MaintGroup=01344”). The intent (e.g., parameter) can be passed in a URL to launchpad and may be defined as part of a target parameter mapping. These parameters may be used for the resolution of a target application as filter criteria to match parameters with values defined in the target parameter mapping. Alternatively, default values for parameters not explicitly passed as URL parameter can be defined. These will then be passed to the target application in addition to parameters supplied in the URL. It is possible to assign fixed values as default values if, for example, no value is provided to as URL parameter. In this example, the default value is passed to the target application at runtime.

FIG. 4 is a block diagram showing an example call sequence 400 for target and parameter mapping. In general, the architecture described herein supports UI5 (e.g., SAP.UI5/HTML/FIORI) based applications, but can also support other UI technologies, including, but not limited to WebDynPro, WebGUI, and SAPGUI. Depending on the target application type, the architecture can map intent (e.g., context) application parameters to technical parameters of a target application.

As shown in FIG. 4, if the platform is HTML5, the launchpad 112 associated with the architecture 402 can pass parameters directly throughout the applications. For non-HTML5-based UIs (e.g., applications), a new URL may be generated by the architecture. For example, the launchpad 112 can attempt to resolve an intent (e.g., context) of a received application request at arrow 402. A navigation target resolution engine 406 can resolve the intent by asking the customer based launchpad 408 for a parameter mapping 410, as shown by arrow 412. The customer based launchpad 408 may provide a new URL configured by backend system 208 to the launchpad 112. The new URL 414 may be an updated URL with transformed parameters based on the target and parameter mapping. The target application is then started (e.g., and hosted) in an inline frame (iFrame) 416 with the updated URL.

For WebDynpro applications and WebGUI transactions, the architecture can target the parameter mapping defined in launchpad customizations (e.g., transaction LPD_CUST) in the frontend server 230 using backend system 208, NWbC HTML 418 and WebGUI 420. In this example, it is also possible to define fixed values and decide to override source parameter values with them. In addition, parameter names can be remapped.

For HTML5 based applications, the launchpad 112 can use the component indicated in the target mapping to request or initiate backend system 208 to instantiate and resolve parameters using either HTML which may be passed as a JavaScript object into the component data of a particular component in the HTML5 architecture. Parameter defaulting (and renaming) may not be directly visible and may not alter an associated hash fragment displayed to the end-user in an outer iFrame. This may allow an administrator to change defaults or alter an assigned application while retaining the semantic meaning of the intent. The link will then point to a new application with a new default.

Parameters are generally transmitted as URL parameters to applications when the applications are started by a user launchpad. Existing applications based on legacy UI technologies (WebDynpro, WebGUI) can be controlled from extern via URL parameters. Thus, to achieve a consistent behavior across multiple UI technologies, the architecture described herein can landscape with a number of back-end systems and also non-ABAP based cloud applications (e.g., Success Factors, Ariba, etc.), which can be supplied by FLP with the same parameters.

The application parameters may be similar to the parameters described herein, but they may not correspond to the SET/GET parameters in an existing AbAP suite. The parameters described in this disclosure include a new set of parameters, which names may be based on a global fieldname catalog. The parameters may be defined in the inbound signature of an applications (located in the application descriptor) that functions to collect information during the lifecycle of a particular application. Applications may map the new parameters to existing SET/GET-parameters in case of ABAP backend systems. Launchpad functionality can provide the user settings service 241, which provides an interface for client-side plug-ins. The plugins are implemented by applications. For each parameter, there may be an implementation in one plug-in. The plug-in implementation may provide user-specific parameter values as well as data used by the parameter settings UI (i.e., language dependent texts and value help). To gather such information, plug-ins may connect via the Gateway System to an application specific User Settings Service (e.g., OData) in the backend system. The OData Service implementation may get values from corresponding SET/GET parameters (in case of an ABAP backend system), derive the value from organizational structures or use any other User Context Persistency as a source. Plug-ins and corresponding OData Services may also be implemented by non-ABAP based cloud applications. The user based launchpad service may call the plug-in implementations at target resolution or before an application is started if parameter values are requested and no value is available from another source. It may distinguish storable and not-storable parameters (information provided by the plug-in implementation). Values of storable parameters are persisted on the Frontend server in a user context persistency. This makes it possible to transport all persisted parameters of the current user to the client when the user based launchpad is started and cache the data in the resource cache in a browser. This can provide an advantage of avoiding subsequent backend requests and achieve optimal performance.

URLs and contained URL parameters may be communicated unencrypted and stored intermediately by browsers. For this reason user default parameters may not be defined for security sensitive data. The similarities are restricted to the parameters maintained with the user profile.

In some implementations, the parameters described throughout this disclosure may be defined in an application descriptor. The application descriptor may be used with the architecture described herein to define an app as an entity, which can be started with a unique URL. This URL can be a tile in a Fiori Launchpad or a catalog entry. In the ABAP context, this can be a UI5 repository (technically a BSP application). It can also be a re-use component, which is transformed to an app with configuration, e.g. a fact sheet. A physically deployable app can become several logical apps which can be consumed independently by configuration.

As described above, the application descriptor 248 may describe an application 246 to make it identifiable. The application 246 will thus have a unique identifier and version. There may be one application 246 delivered for one application version. The application descriptor 248 may also persist any target mapping.

Application parameters are defined as part of the inbound signature of the application. If a parameter should be supplied by the launchpad with a user-default at application startup, the default property has to reference the corresponding UserDefaultParameter as shown in the following example application descriptor excerpt:

Application Descriptor

“crossNavigation” : {

“inbounds” : [ {

“signature” : {

“parameters” : {

“GLAccount” : {

“default” : {

“value” : “UserDefaultParameters.GLAccount”,

“format” : “reference”

},

“required” : true,

}}}} ]}

In one example implementation, each application component supplies a plug-in to perform the following tasks (1) Runtime use-case: Retrieve backend-configured parameter values (2) Editing time use-case (in addition to (1)): Retrieve metadata for a parameter and enable valuehelp and validation. Optionally write back changes into the backend.

These plug-ins may be delivered by launchpad plug-ins and configured via the standard role-specific plug-in mechanism. When the runtime requires a parameter value, plug-ins will be invoked, passing the current value (if present) of a parameter. The general plug-in will accept a user-defined value already present in the storage. If no value is yet present and the plug-in is responsible for a given parameter key, it will typically perform a request to the backend system 208, to retrieve (a set of) backend-configured parameters, as shown in FIG. 4. If the requested parameter is defined on the backend, it will return this parameter value to the UserDefaultService. Typically the UserDefaultService will then persist the parameter value, and on subsequent attempts to retrieve the parameter, the plug-in may not perform another roundtrip. Via this mechanism, backend configured values are migrated to the UserDefaultSettings of the frontend server without changes. In some implementations, the plug-ins are informed about every parameter request and every change. Thus the protocol allows for refined scenarios, e.g., the plug-ins may react on changes on the stored value on the frontend server 230 (e.g. when a user edits a value) and also update a persistence on the backend server 208. This allows persistence of central settings to be in sync with SET/GET parameters on the backend system 208.

In addition to retrieving the parameter value (and potentially writing it back), the editing plug-ins may be built as an extension of the runtime plug-in, as the functionality is not needed during runtime. The editing interface can provide functionality to (1) Provide suitable metadata for a parameter, notably whether it shall be user editable (2) enable the UI to represent the value in a common format (3) enable the User Interface to perform a validation for the parameter (4) and enable the UI to invoke a value help for the parameter.

In some implementations, the architecture described herein can determine parameters using a signature. For example, default parameters in a signature may refer to UserDefaultParameters. The default parameters are configured to be used by an application if the URL contains already a value for a parameter this parameter will be used. If the value is requested, an attempt is made to determine the value, as described above. If no value can be obtained (after asking all plug-ins), the target mapping will treat the value as if not supplied. A filtering mechanism gives an application the ability to either reject the signature or accept it (potentially providing a hard-coded default later).

Typically parameters based on existing parameters retrieve parameters from an existing storage on the backend server (that the plug-in connects to) once upon startup. The value is then propagated in the frontend server persistence, and subsequently used. These values are cached in the Browser Cache, on subsequent request only a cache-busting timestamp is retrieved. The user may manually edit the parameters, changing parameters only in the front end server persistence. During the editing value helps and validation is performed against the specific backend system. Parameters which are no longer relevant for a user, according to his assigned roles, may be removed from the user parameter settings service 241, for example.

The storage repository on the Frontend server may be coupled to typical personalization data. For example, it may be possible to remove this personalization for a specific user, copy a user (e.g., create a copy of the personalization data associated with a new user), and rename a user without losing the data.

A local copy may be maintained within the client, which is retrieved only at certain times. Parallel editing of parameters or updating of parameters in different sessions are not immediately reflected in different session. The user can achieve eventual consistency by refreshing design tools, to see the current backend state. We deliberately gear the system towards performance at the loss of atomicity. Runtime and design tools and runtime may optimize for the critical path, deferring auxiliary updates and synchronizations to suitable times (e.g. form exiting), risking potentially data loss upon intermediate browser window death.

FIG. 5 is an example screenshot 500 of an example settings UI 235. The end-user will be able to check and enter default values for parameters in a central settings UI application provided by a user settings service 241. This application may be delivered as an explicit FIORI application or be accessible from a main menu of the launchpad.

The settings UI 235 shall may display only parameters, which are relevant for the current user. The parameters displayed in the UI may be collected from user default parameters referenced in the inbound signature of applications assigned to the role or user, respectively. It is expected that there are about twenty to about thirty parameters relevant for one user (across all applications). The parameters may be displayed in a list, as shown by settings panel 502, which are displayed in a list.

All data (e.g., parameters, language dependent texts, value help, etc.) used by the UI may be provided by the launchpad (e.g., using service 241), which retrieves information from plug-ins and delegates calls to the plug-ins. The settings UI 235 may present parameters in a user-legible way (e.g., in a translated descriptive text) and allows the user to enter and validate values in a corresponding format (e.g., Type, UI representation, value helps, etc.). For this purpose, the applications exposing parameters can enable the settings UI 235 to attach to an OData service providing the respective value help, validation, and metadata information. In operation, the editor may allow the use of the plug-in mechanism to expose relevant metadata (e.g., descriptive text of parameter name, OData service, entity property for value help and type information). The settings UI 235 can use a smart infrastructure to enable a consistent and helpful user experience.

The user can interact with settings UI 235 to select a user account 504, profiling personalized search data 506, notifications, 506, appearance 508, language and region 510, cross application standards 512, and default values 514, just to name a few. Default values 514 is shown at panel 516. The default values include which plant (or plants) apply to a particular user, as shown by dropdown 518 and 520. Similarly, additional options including particular relevant documents 522, delivery information 524, and cost centers 526 can be configured as default parameters.

FIG. 6 is a flowchart that illustrates a method 600 for populating and transferring parameters across a plurality of applications executable on multiple user interface platforms. At block 602, the method 600 can include receiving, at a server device, a request to launch a first application executing on a first user interface platform. For example, a user can access a client device and request to launch an application executing on an HTML5 based platform. In general, the plurality of applications are configured to execute on the plurality of user interface technologies (e.g., platforms) in parallel to provide the same user interface functionality using the plurality of parameter values.

At block 604, the method 600 can include accessing a plurality of parameter values and populating, with the plurality of parameter values, fields in user interfaces associated with the first application. The parameter values may represent default values configured for a user requesting the launch of the any of the applications described herein. In some implementations, the parameter values are predefined by a user in a third application provided by the architecture and used for configuring settings. For example, the user can access a settings UI, such as UI 235 to configure parameters and values for the parameters. In some implementations, the parameter values are automatically derived based on a role of a user associated with at least one application provided by at least one user interface platform.

At block 606, the method 600 can include receiving a request to launch a second application executing on a second user interface platform. For example, the server may receive a request to launch the second application on an SAPGUI platform. In response to receiving a request to launch the second application executing on the second user interface platform, the method 600 can include accessing a signature associated with the first application and determining that the signature matches a predefined signature associated with the second application, at block 606A. For example, the server can access a database to retrieve a signature associated with the first application and stored prior to receiving, from the user, a launch request for the second application. The retrieved signature can be matched to the predefined signature (e.g., associated with the user and/or a role of the user in the architecture).

At block 606B, the method 600 can include determining a portion of the plurality of parameter values that are applicable to the second application. For example, the server may have access to all default parameters for the user or for the first application. The server can determine and select a subset of applicable parameters. The determined subset (e.g., portion) can be used to generate one or more URLs that represent the portion of the plurality of parameter values, as described above. The server can then transmit the URLs to the second application and launch the second application based on the matching signature and URL holding the retrieved portion of parameters, at block 606D. At block 608, the method 600 can include populating in at least one user interface corresponding to the second application, a plurality of fields using the portion of the plurality of parameter values associated with the uniform resource locator.

In some implementations, the signature and the uniform resource locator are automatically generated by the first application. In some implementations, the uniform resource locator represents a mapping of a context associated with a user requesting the launch of the second application to a plurality of parameters in the second application

In some implementations, the method may also include generating an updated uniform resource locator that includes default parameters based on the mapping of the context, in response to determining that the user interface platform is a platform other than HTML5 and generating the second application in an inline frame using the updated uniform resource locator.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention.

In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.

Number	Date	Country
62335892	May 2016	US
62335895	May 2016	US
62335897	May 2016	US
62335899	May 2016	US
62335879	May 2016	US
62335883	May 2016	US
62335886	May 2016	US
62335887	May 2016	US

TRANSFERRING PARAMETERS IN APPLICATIONS AND INTERFACES ACROSS MULTIPLE PLATFORMS

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

CROSS REFERENCE TO RELATED APPLICATIONS

Provisional Applications (8)