Patent Publication Number: US-2017371942-A1

Title: Migrating of user interfaces using an enhanced unified metadata repository

Description:
TECHNICAL FIELD 
     The present disclosure relates to computer systems and computer-implemented methods for migrating existing reports to an enhanced user experience. 
     Software developers consistently update and modify systems, applications, and user interface-based software and presentations in an effort to provide customers with the best user experience and technology available. Due to these updates, developers consistently must recreate previous solutions to be used in the new software. Further, when new user experience layers are provided, additional recreations of existing software, including reports, must be recreated to satisfy the requirements of the new systems. 
     Recent software for enhanced user experiences can be used to provide simpler and personalized user experiences with existing software, improve productivity by simplifying legacy applications and tasks, reduce training and support costs with easier-to-use screens, and boost user adoption with appealing designs tailored to key tasks and activities. 
     Further, online and cloud applications may be accessed and executed using REST (representation state transfer)-based services. Such services allow lightweight, maintainable, and scalable services, where the service can be accessed using an HTTP protocol, as well as other suitable protocols. 
     SUMMARY 
     The disclosure generally describes computer-implemented methods, software, and systems for migrating reports to an enhanced user experience are described. An example method includes migrating an existing report to an enhanced user experience application is identified, where the existing report is associated with existing metadata for selection screen presentation and backend coding. A metadata object associated with the identified report is created, and at least some of the existing metadata associated with the identified existing report is replicated into the created metadata object based on the relationship between the existing report and the enhanced report. At least one enhancement to the created metadata object is received, where the at least one enhancement includes at least one additional metadata attribute to be represented in an updated selection screen presentation associated with the enhanced user experience application. The created metadata object is then persisted for later execution. 
     In some instances, a request to execute the identified report in the enhanced user experience application is received. The created metadata object associated with the particular report is identified, and an updated selection screen based at least partly on the identified metadata object is presented, the updated selection screen presentation including the at least one enhancement of the created metadata object applied to the existing metadata associated with the existing report. The identified report is executed based on input received via the updated selection screen, wherein executing the identified report comprises using the backend coding for execution. In some instances, the backend coding for execution comprises the backend coding associated with the existing report. 
     In some instances, the metadata object is associated with the identified report based on a header corresponding to the name of the identified report. The operations may be performed by a generic service operable to migrate any existing report to the enhanced user experience application. In some instances, replicating at least some of the existing metadata associated with the identified existing report into the created metadata object comprises identifying a set of parameters associated with the existing report and incorporating at least a portion of the identified set of parameters into the created metadata object. In some instances, the at least one additional metadata attribute includes layout information associated with the updated selection screen presentation, a determination of one or more mandatory fields within the updated selection screen presentation, a grouping of fields within the updated selection screen presentation, and dependency information between at least two fields in the updated selection screen presentation. In other instances, at least one additional metadata attribute includes a set of coding value help information, the coding value help information identifying a range or type of value information associated with at least one field included in the updated selection screen presentation. 
     The existing report can be associated with a legacy system in some instances. Further, the created metadata object is persisted in the same location as the existing report. 
     While generally described as computer implemented software embodied on tangible media that processes and transforms the respective data, some or all of the aspects may be computer implemented methods or further included in respective systems or other devices for performing this described functionality. Specifically, particular implementations of described methods and systems can include corresponding computer systems, apparatuses, or computer programs (or a combination of computer systems, apparatuses, and computer program) recorded on one or more computer storage devices, each configured to perform the actions of the methods. 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 software, firmware, or hardware installed on the system that, in operation, causes 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. The details of these and other aspects and embodiments of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  is a block diagram illustrating an example system for enabling migration of existing reports into an enhanced user experience environment. 
         FIG. 2  is a simplified diagram presenting connections between elements of example  FIG. 1 . 
         FIG. 3  is an illustration of example operations for generating an enhanced metadata layer for presenting and executing existing report functionality in an enhanced user experience environment. 
         FIG. 4  is an illustration of example operations for executing a report in the enhanced user experience environment based on the additional metadata layer and existing report functionality. 
         FIG. 5  is an example illustration of a screen selection element of an existing report. 
         FIG. 6  is an example illustration of a set of parameters associated with a particular report and its existing metadata. 
         FIG. 7  is an example illustration of an enhanced screen selection element of a migrated report for use in the enhanced user experience environment. 
         FIG. 8  is an illustration of an example swim lane diagram associated with operations for executing a report in the enhanced user experience environment. 
     
    
    
     DETAILED DESCRIPTION 
     This present disclosure generally describes computer-implemented methods, software, and systems for migrating existing reports into an enhanced user experience (UX) application. Specifically, reports created and existing in one or more existing systems may be readily available. When businesses and developers provide an advanced (and enhanced) UX, however, these existing reports must be recreated in order to take advantage of the experience provided by the advanced systems. In the present solution, these existing reports are migrated to the enhanced UX via migration of the selection screens associated with those reports, where the reports comprise two distinct parts: the selection screens identifying inputs upon which the report is to be based, and backend coding in the system in which the existing report is located that is used to execute the reports once inputs are provided. The reports are executable programs that read data from an underlying database or data store and generates output based on the filter criteria as selected by the end user via the selection screen. The output may include a result presentation to a user, the generation of a log, or execution or actions performed by the backend system or another related system in response to the output. 
     In one example, reports may initially exist in a client/server model-based system that provides the ability to store, retrieve, analyze, and process business processes and related data. However, newer systems may provide an in-memory computing platform designed to run on any database platform, where said platform may be associated with an enhanced UX application providing modern design principles, including device-agnostic user interfaces (UIs) that allow easy porting of applications to any suitable client, including mobile devices. The existing reports may not be formatted for or available in the enhanced UX application. In many instances, the existing reports may be associated with background jobs for the existing or prior system, such that a mechanism is needed to migrate and subsequently run the reports in the new system. The present solution provides a generic solution for migration of existing reports to be associated with the new system and its enhanced UX application with minimal adoption effort, thereby avoiding costly rework of the already available existing report. While the primary benefit of the migration may include moving from previous systems to new systems, the generic solution allows for migration of both legacy reports and current reports. In other words, not only may the legacy reports be migrated with additional enhancement, but existing reports in the current system may also be migrated and enhanced with the current solution, allowing users and developers a simple and lightweight report enhancement solution. 
       FIG. 5  illustrates an example illustration of a screen selection element  500  of an existing report to be migrated. The existing report includes two pieces, the UI coding identifying the particular parameters and fields to be presented when initiating the report, as well as the backend coding performed by the system with which the existing report is associated. The screen selection element  500  includes a plurality of fields related to an application job demo report  502 , including selection fields  504  of “Process Buyers” and “Process Sellers,” among other fields and related sub-fields. These selectable and/or input-based fields represent parameters associated with the report, and can be used to determine the operations performed when the report is executed. 
       FIG. 6  illustrates a set of metadata associated with the existing report that is used during the migration process. The set of metadata corresponds to a newly created metadata object  600 , the application job catalog entry metadata object  600 . As illustrated, the application job catalog entry metadata object  600  replicates at least a portion of the information included in metadata used to define the selection screen of the application job demo report  500 . Specifically, the parameters and at least a portion of their metadata defining the presentation of the selection screen is included in the new object  600 . However, the application job catalog entry metadata object  600  can be modified to create an enhanced selection screen for use in the enhanced UX application. In doing so, the incorporated metadata can be modified as desired, while retaining the backend coding for use in executing the underlying report. For example, particular parameters can be associated within a group, thereby defining how the parameters will be presented on the UI. Additionally, one or more of the parameters may be made mandatory such that an entry is required, while one or more of the other parameters are hidden. Further, specific positions of the parameters in the UI can be updated or changed, as well as their indention or other presentation specifics, among others. Once the specifics of the updated metadata are defined, the application job catalog entry metadata object  600  can be stored apart from the original report. The job catalog entry metadata object  600 , however, can be accessed upon and used in the execution of the report in the enhanced UX application. 
     The solution for generating the enhanced report includes two pieces: the UI coding and the backend coding associated with the existing report. The UI and backend can communicate with each other, e.g., through an OData service. In one solution, the OData service may be SAP&#39;s Gateway, a technology that provides a simple way to connect devices, environments, and platforms to SAP software. The gateway, for example, can manage communications between distinct systems via OData protocols. The gateway may include additional services and operations, including validation of fields for entries in particular selection screens prior to providing the input to the backend system. 
     The backend coding executes based on the inputs from the selection screens, and is capable of accessing the existing metadata managing the execution of the reports. The information including this metadata is exposed via the generic OData service to the UI, such that a single OData service can be generically used for all reports without requiring each report to use its own OData service. 
     The gateway and/or the particular gateway service dedicated to the migration of the reports performs operations to merge the metadata of the existing report with the enhanced metadata object based on the association of the metadata object to the existing report. In some instances, the gateway can further ensure that checks on the data are performed, as well as manipulation of the particular parameter values. 
       FIG. 7  illustrates the migrated selection screen of the report after the merging of the existing metadata and the created metadata object is performed. Specifically, the migrated selection screen is illustrated in the enhanced UX application. The enhanced UX application renders the existing report from above based on the merged metadata information—that is, as illustrated the parameters are grouped in different sections and include indentions as specified in the enhanced metadata object  600  of  FIG. 6 . For example, the “Process Buyers” selection field  610  is now grouped with the “Plant” text box  615  and the “Date” text box  620  in the Buyer group  605 , with the Plant  615  and Date  620  boxes dependent upon and indented from the Process Buyers selection field  610 . The dependency information means that in order for Plant  615  and Date  620  to be editable, the Process Buyers field  610  must be selected/activated. Similarly, the “Process Sellers” selection field  630  and the “Increase” text box  635  are grouped together in the Seller group  625 , with the “Increase” text box  635  dependent on and indented from the “Process Sellers” field  630 . The additional parameters  645  are associated with the General group  640  as defined in the metadata object  600 . 
     Turning to the illustrated embodiment,  FIG. 1  is a block diagram illustrating an example system  100  for enabling migration of existing reports into an enhanced user experience environment as illustrated above. As illustrated in  FIG. 1 , system  100  is a client-server or cloud-based system capable of migrating one or more existing reports defined in a backend system to be used or presented in an enhanced UX application, such as the UX system  160  illustrated in  FIG. 1 . The migration process can enhance reports  123  located at backend system  102  using a set of migration UI metadata  132 , where the existing metadata  126  associated with the existing report  123  is merged with the migration UI metadata  132  (as defined by a user or administrator) by the gateway system  140  and executed within the UX system  160  for presentation to one or more clients  180 . In some instances, the backend system  102  may be a legacy system in which the existing reports  123  have been previously generated and executed. In other instances, the backend system  102  may be a current system, where the migration operations are used to customize or otherwise modify or enhance particular reports. 
     As illustrated, system  100  includes or is communicably coupled with the backend system  102 , gateway system  140 , UX system  160 , and client  180 , where these systems are connected, at least in part, by network  155 . Although components are shown individually, in some implementations, functionality of two or more components, systems, or servers may be provided by a single component, system, or server. Similarly, in some implementations, the functionality of one illustrated component, system, or server may be provided by multiple components, systems, servers, or combinations thereof. Conversely, multiple components may be combined into a single component, system, or server, where appropriate. 
     As used in the present disclosure, the term “computer” is intended to encompass any suitable processing device. For example, client  180 , backend system  102 , gateway system  140 , and UX system  160 , among other illustrated and non-illustrated components, may be any computer or processing device such as, for example, a blade server, general-purpose personal computer (PC), Mac®, workstation, UNIX-based workstation, smartphone, tablet, or any other suitable device. Moreover, although  FIG. 1  illustrates the various elements individually (e.g., the backend system  102 ), any such systems can be implemented using two or more systems, as well as computers other than servers, including a server pool. Alternatively, the functionality provided by some portions of the system  100  may be included (in whole or in part) at one or more other components within the system  100 . In some instances, the network  155  may provide cloud-based solutions for any of the elements, as well as other suitable combinations and permutations. The present disclosure contemplates computers other than general purpose computers, as well as computers without conventional operating systems. 
     In general, the backend system  102  is a system associated with one or more reports  123  in a report repository  120 , where each report  123  is associated with a set of report metadata  126  and report coding  129 . The report metadata  126  for each report identifies particular parameters or attributes associated with the report, including items for which user input is to be requested. The report coding  129  includes executable code for use in executing the corresponding report  123  upon receipt of the associated inputs to the report  123  (as provided by a user or automatically by the system). 
     As illustrated, the backend system  102  includes an interface  105 , a processor  108 , a set of backend operations  111 , and memory  117 . The interface  105  is used by the backend system  102  for communicating with other systems in a distributed environment—including within the environment  100 —connected to the network  155 , e.g., gateway system  140 , UX system  160 , client  180 , as well as other systems communicably coupled to the network  155 . Generally, the interface  105  comprises logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network  155 . More specifically, the interface  105  may comprise software supporting one or more communication protocols associated with communications such that the network  155  or interface&#39;s hardware is operable to communicate physical signals within and outside of the illustrated environment  100 . 
     Network  155  facilitates wireless or wireline communications between the components of the environment  100  (e.g., between the backend system  102  and the gateway system  140 , between the UX system  160  and the gateway system  140 , between client  180  and the UX system parser system  160 , as well as with any other local or remote computer, such as additional clients, servers, or other devices communicably coupled to network  155 , including those not illustrated in  FIG. 1 ). In the illustrated environment, the network  155  is depicted as a single network, but may be comprised of more than one network without departing from the scope of this disclosure, so long as at least a portion of the network  155  may facilitate communications between senders and recipients. In some instances, one or more of the illustrated components may be included within network  155  as one or more cloud-based services or operations. The network  155  may be all or a portion of an enterprise or secured network, while in another instance, at least a portion of the network  155  may represent a connection to the Internet. In some instances, a portion of the network  155  may be a virtual private network (VPN). Further, all or a portion of the network  155  can comprise either a wireline or wireless link. Example wireless links may include 802.11a/b/g/n/ac, 802.20, WiMax, LTE, and/or any other appropriate wireless link. In other words, the network  155  encompasses any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components inside and outside the illustrated environment  100 . The network  155  may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. The network  155  may also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the Internet, and/or any other communication system or systems at one or more locations. 
     The backend system  102  further includes processor  108 . Although illustrated as a single processor  108  in  FIG. 1 , two or more processors  108  may be used according to particular needs, desires, or particular implementations of the environment  100 . Each processor  108  may be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another suitable component. Generally, the processor  108  executes instructions and manipulates data to perform the operations of the backend system  102 . Specifically, the processor  108  executes the algorithms and operations described in the illustrated figures, including the operations performing the functionality associated with the backend system  102  generally, as well as the various software modules and operations (e.g., the backend operations  111  and report execution module  114 ), including the functionality for sending communications to and receiving transmissions from the various systems involved in the migration and execution of reports. 
     As noted, the backend system  102  includes and performs a set of backend operations  111  associated with the normal functionality of the backend system  102 , including a report execution module  114  for executing the functionality associated with each of the reports  123 . Specifically, the report execution module  114  can access the report coding  129  associated with particular reports, and use inputs associated with the report  123  to execute the functionality and coding of the report  123 . The backend operations  111  and report execution module  114  may be applications, set of applications, software, software modules, or combination of software and hardware used to perform the operations of the backend system  102 . 
     Regardless of the particular implementation, “software” includes computer-readable instructions, firmware, wired and/or programmed hardware, or any combination thereof on a tangible medium (transitory or non-transitory, as appropriate) operable when executed to perform at least the processes and operations described herein. In fact, each software component may be fully or partially written or described in any appropriate computer language including C, C++, JavaScript, Java™, Visual Basic, assembler, Perl®, any suitable version of 4GL, as well as others. 
     The backend system  102  also includes memory  117 , or multiple memories  117 . The memory  117  may include any memory or database module(s) and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. In some instances, at least a portion of the memory  117  may include an in-memory database. The memory  117  may store various objects or data, including financial data, user information, administrative settings, password information, caches, applications, backup data, repositories storing business and/or dynamic information, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the backend system  102 . Additionally, the memory  117  may store any other appropriate data, such as VPN applications, firmware logs and policies, firewall policies, a security or access log, print or other reporting files, as well as others. As illustrated, memory  117  can store the report repository  120  (described above), the migration UI metadata  132 , and a coding value help repository  138 , as well as any other information relevant to the backend system  102 . 
     The report repository  120  may be a single repository, database, or storage location associated with the reports  123  in some instances. In others, the report repository  120  may be a plurality of repositories, databases, or storage locations at which the reports  123  are located. In some instances, some or all of the report repository  120  and the reports  123  inside may be located apart from the backend system  102 . Generally, the reports  123  in the report repository  120  are not modified during the migration process, as the additional migration UI metadata  132  provides for enhancements on a layer above the reports  123 , with the gateway system performing the merging of the metadata at execution time to allow for presentation of the corresponding enhanced selection screens. In some instances, the report repository  120  and the migration UI metadata  132  can be combined into a unified metadata repository where all metadata, both existing and enhanced, associated with particular reports is stored for quick and efficient accessing and processing by the enhanced UX application and the backend system  102 . 
     The migration UI metadata  132  can include one or more created metadata objects used to extend and migrate particular reports  123  to an enhanced UX application, such as the UX system  160 . In particular, the migration UI metadata  132  can be used to modify, update, and alter the presentation of selection screens associated with the report  123 , and therefore alter the presentation of the report screens as presented to the user, e.g., at client  180 . The migration UI metadata  132  can include one or more report instance metadata objects  135 , where the report instance metadata objects  135  are merged with the report metadata  126  at runtime to migrate the reports to the enhanced UX application. In doing so, the report instance metadata objects  135  can define modified presentation parameters and attributes associated with the migrated report, where such modifications can result in an enhanced presentation of the selection screens as illustrated in the examples of  FIGS. 5 through 7 . Importantly, the migration UI metadata  132  does not affect the underlying execution of the report  123 —specifically, the report coding  129 . Instead, the migration UI metadata  132  can define changes to the presentation of the selection screen and modify the information collected for passing to the report coding  129  for execution by the report execution module  114 . The report instance metadata object  135  may be associated with or linked to a particular report  123  in various ways. In generating the report instance metadata object  135 , at least a portion of the underlying report metadata  126  for the migrated existing report  123  may be replicated and/or imported into the new object. This information can include header information, specific linking information (e.g., based on unique report identifiers), and other association information. At execution, the relationship between the report instance metadata object  135  and the existing report  123  can be identified and used to merge the existing report metadata  126  with the enhanced metadata object  135 . 
     The coding value help repository  138  includes various coding value assistance as defined by users. Specifically, during the process of defining one or more enhancements to the report  123  as described herein, one or more coding value help actions may be defined. The coding value help actions include input assistance when an end user activates, for instance, help functionality associated with the report  123  and its selection screen (e.g., by pressing the “F4” key). In some instances, one or more dedicated searches may be provided within the migrated selection screen using the coding value help repository  138  and its metadata, such that users may enter text into a text field for searching dedicated or particular topics or data. 
     The illustrated environment  100  further includes gateway system  140 . Gateway system  140  provides a method of communication between the UX system  160  and the backend system  102  through a provided OData service. As illustrated, the gateway system  140  includes interface  142 , process  144 , gateway operations  146 , and memory  150 . The interface  142  and processor  144  may be similar to or different than interface  105  and processor  108 . In general, processor  108  executes instructions and manipulates data to perform the operations of the gateway system  140 . Specifically, the processor  144  executes the algorithms and operations associated with the gateway system  140 , including the operations associated with merging the existing report metadata  126  with the migration UI metadata  132  (and particular report instance metadata  135 ) corresponding to a particular report instance being executed at the UX system  160 , as well as the normal gateway operations  146  associated with the gateway system  140 . Further, memory  150  may be similar to or different than memory  117 . While illustrated generally, memory  150  may store or maintain information related to the gateway system  140 . 
     As illustrated, in addition to the standard gateway operations  146  used to connect different systems, the gateway operations  146  include a metadata merge module  147  and a report coding logic module  148 . The metadata merge module  147  performs operations to merge, in response to requests to execute a migrated report  123 , the existing report metadata  126  and the corresponding report instance metadata  135  included in the migration UI metadata  132 , thereby enabling the execution of the migrated report  123  in the enhanced UX application. The report coding logic module  148  of the gateway operations  146  performs actions to process the input provided by users or the system within particular selection screens to perform the additional checks and/or manipulation of parameter values to ensure proper execution of the report  123 . One example may be realized in a materials requirement planning application execution. A particular exit performed by the report coding logic module  148  may include checking if a combination of a product and associated plan are valid before submitting the inputs to the backend. For example, manipulation of a particular parameter may be such that the system determines a default cost center of an employee where no cost center is provided as input. Alternatively, if a parameter is incorrectly entered, the report coding logic module  148  may identify an intended parameter matching the other input, and can automatically update the input prior to providing to the backend system. Other similar and different checks and manipulations may be available through the logic and capabilities of module  148 . 
     UX system  160  represents a system providing an enhanced UX application  166 . One example system may include an implementation of an SAP FIORI UX system. In general, the UX system  160  is able to provide a personalized and role-based user experience for enterprise-wide engagement across lines of business, across various applications, and across any number of deployment options. The UX system  160  provides optimal usability on multiple devices for quality presentations on various devices and ecosystems to increase the ease of use for users. Specifically, the UX application  166  applies modern design principles to new and existing applications, including for presentations of reports and other content. In the present illustration, the UX system  160  acts as a presentation layer to the execution of the various report  123 , with the gateway system  140  performing the merge operations to collect and integrate the metadata  126 ,  135  associated with a particular report  123 . The UX application  166 , interpreting and using the combined metadata, presents a selection screen associated with the requested report. The selection screen allows user inputs of one or more parameters. Upon submission, the gateway system  140  connects with the original report coding  129  and the report execution module  114  to execute the report  123 . 
     As illustrated, the selection screen service  168  of the UX system  160  allows users to migrate reports  123  to the enhanced system. Specifically, the selection screen service  168  allows users to create the enhanced metadata by identifying the report for migration, creating a metadata object associated with the identified report (e.g., based on a shared name, header, unique identifier, etc.), and replicating at least some of the existing metadata associated with the existing report into the created metadata object. The selection screen service  168  can then receive at least one metadata-based enhancement to the created metadata object, the enhancement representing at least one modified or new metadata attribute. The created metadata object is then persisted for later execution as described herein. In some instances, the created metadata object (e.g., the report instance metadata  132 ) is stored at or in the same location of the report repository  120  storing the associated report  123 . In other instances, the object may be stored apart and/or remotely from the report repository  120 . In some instances, the created metadata object may be enhanced with one or more coding value helps as described herein. Those helps can be stored with or apart from the migration UI metadata  132  in the coding value help repository  138 . 
     The UX system  160  includes interface  162 , processor  164 , and memory  170 . The interface  162  and processor  144  may be similar to or different than interfaces  105 ,  142  and processors  108 ,  144 . In general, processor  164  executes instructions and manipulates data to perform the operations of the UX system  160 . Specifically, the processor  164  executes the algorithms and operations associated with the UX system  160 , including the operations associated with presenting and migrating reports  123  and their selection screens to a user, such as a user of client  180 . Memory  170  may be similar to or different than memory  117 ,  150 . While illustrated generally, memory  170  may store or maintain information related to the UX system  160 . 
     In some instances, the UX system  160  may be a standalone system. Alternatively, the UX system  160  may be included in or part of another system, such as client application  186  of the client  180 , as well as a cloud-based system or application. 
     Environment  100  includes one or more clients  180 . Particular clients  180  may connect to any of the illustrated systems, and may include end users, developers, and administrators. For purposes of the actions described herein, client  180  may connect to the UX system  160  in migrating and executing particular reports  123 . Each client  180  may be specifically associated with a particular user or multiple users. In other instances, clients  180  may be generally available computing systems accessible by a plurality of users. As illustrated, users may perform migration operations via client application  186 , which may include or be associated with a web browser, a remotely executed application associated with the UX system  160 , or any other suitable application or component. The client application  186  may be associated with an application window or presentation (e.g., GUI  188 ) used to present information associated with that application  186  to the user regarding particular reports  123  and their corresponding selection screens. 
     The illustrated client  180  is intended to encompass any computing device such as a desktop computer, laptop/notebook computer, mobile device, smartphone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, or any other suitable processing device. In general, the client  180  and its components may be adapted to execute any operating system, including Linux, UNIX, Windows, Mac OS®, Java™, Android™, or iOS. According to one implementation, the illustrated systems may also include or be communicably coupled with a communication server, an e-mail server, a web server, a caching server, a streaming data server, and/or other suitable server or computer. In some instances, the client  180  may comprise a computer that includes an input device, such as a keypad, touch screen, or other device(s) that can interact with the client application  186 , and an output device that conveys information associated with the operation of the applications and their application windows to the user of the client  180 . Such information may include digital data, visual information, or a GUI  188 , as shown with respect to the client  180 . Specifically, the client  180  may be any computing device operable to connect to or communicate with the UX system  160 , the backend system  102 , the gateway system  140 , other clients  180 , and/or other components via network  155 , as well as with the network  155  itself, using a wireline or wireless connection. In general, client  180  comprises an electronic computer device operable to receive, transmit, process, and store any appropriate data associated with the environment  100  of  FIG. 1 . 
     As illustrated, client  180  includes an interface  182 , a processor  184 , client application  186 , a graphical user interface (GUI)  188 , and memory  190 . The interface  182  and processor  184  may be similar to or different than the interfaces and processors of  FIG. 1 . In general, processor  184  executes instructions and manipulates data to perform the operations of the client  180 . Specifically, the processor  184  executes the algorithms and operations described in the illustrated figures and associated with the client  180 , including the operations performing the functionality associated with the client application  186 . In some instances, the client  180  may be integrated with the UX system  160 , either by inclusion of the UX application  166  with the client  180 , or by a remote connection for executing the UX application  166 . The processor  184  can manage such executions. Further, memory  190  may be similar to or different than the other memories described in  FIG. 1 . While illustrated generally, memory  190  may store or maintain information related to the client  180 , as well as other suitable data. 
     GUI  188  of the client  180  interfaces with at least a portion of the environment  100  for any suitable purpose, including generating a visual representation of the client application  186  and/or the UX application  166 . In particular, the GUI  188  may be used to view a selection screen presentation associated a particular report  123 , as well as the selection screen service  168  used to migrate one or more reports  123  for execution in conjunction with the UX system  160 . GUI  188  may also be used to view and interact with various Web pages and applications located local or external to the client  180 . Generally, the GUI  188  provides the user with an efficient and user-friendly presentation of data provided by or communicated within the system. The GUI  188  may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by the user. For example, the GUI  188  may provide interactive elements that allow a user to view or interact with information related to the operations of the process associated with the selection screen service  168 . In general, the GUI  188  is often configurable, supports a combination of tables and graphs (bar, line, pie, status dials, etc.), and is able to build real-time portals, application windows, and presentations. Therefore, the GUI  188  contemplates any suitable graphical user interface, such as a combination of a generic web browser, a web-enable application, intelligent engine, and command line interface (CLI) that processes information in the platform and efficiently presents the results to the user visually. 
     While portions of the elements illustrated in  FIG. 1  are shown as individual modules that implement the various features and functionality through various objects, methods, or other processes, the software may instead include a number of sub-modules, third-party services, components, libraries, and such, as appropriate. Conversely, the features and functionality of various components can be combined into single components as appropriate. 
       FIG. 2  is a simplified diagram presenting connections between elements of example  FIG. 1 .  FIG. 2  is similar to the components of  FIG. 1 , but is not intended to be an identical representation. As illustrated, environment  200  includes a UX system  202 , a gateway service  206 , and one or more existing systems  208 . 
     As illustrated, the UX system  202  and the existing systems  208  can communicate via the gateway service  206 . Existing reports can be stored in the report repository  212  (including both existing report metadata and existing report coding for execution). In some instances, those reports may be in a legacy format, where the migration process moves the legacy presentation into the enhanced UX presentation. In other instances, the reports may be available in a current format, where the migration modifies the presentation of the report for a customized experience. This is especially helpful where the existing report is pre-configured by a developer, where customers and end users wish to create customized reports and selection screens for their users and/or themselves. 
     Via the UX system  202  and its generic selection screen service  204 , a particular existing report for migration can be selected. Upon selection, a metadata object associated with the identified report is created. Here, that created metadata object is stored with the additional UI metadata repository  210 . While illustrated in the existing system  208 , the additional UI metadata repository  210 , or a portion thereof, may be located elsewhere in any suitable location. In response to the creation, at least some of the existing metadata associated with the identified existing report is replicated into the created metadata object. Such replication can assist in associating the additional metadata object with the existing report, as well as the inclusion of a listing of parameters associated with the existing metadata. Once the data is replicated, at least one enhancement to the created metadata object is received, where the enhancement(s) include and/or identify at least one attribute to be represented in an updated selection screen presentation for use in executing the existing report via the UX system  202 . Such enhancements may include grouping one or more of the parameters in the presentation, changing indention of the parameters as they are presented, hiding one or more previously presented parameters in the enhanced selection screen, adding dependency relationships between two or more of the parameters, change parameter presentation (e.g., names or labels), as well as others. Once complete, the created metadata object is persisted for future execution. In some instances, the generic selection screen service  204  can allow users to add one or more coding value help options and implementations. These may be stored in a coding value help implementation repository  214 , or they may be stored with the additional UI metadata  210 . 
     To execute a migrated report, the user can submit a request via the UX system  202  to execute the report. The request is sent via the gateway service  206 , which manages the merging of metadata for execution of the migrated report. The gateway service  206  can identify whether additional UI metadata  210  associated with the requested report exists, in particular the created metadata object. The gateway service  206  can also access the existing metadata from the report repository  212  to generate a combined set of metadata, which is passed to the UX system  202  and is there used to interpret and present the updated selection screen based on the enhancements form the metadata object. As inputs are received through the UX system  202 , they are passed via the gateway system  206  to the report repository  212  and the corresponding backend system (not illustrated) for execution. As described above, the existing coding can interpret the received input and execute without requiring any coding changes to the execution portion of the report. In some instances, the gateway service  206  may include coding logic  208  to assist in the report execution, where the coding logic can perform one or more validations of the received input before passing the input to the report code at the backend system. Other checks of the input data may be performed by the gateway service  206  and/or any other suitable component. 
       FIG. 3  is an illustration of example operations for generating an enhanced metadata layer for presenting and executing existing report functionality in an enhanced user experience environment. For clarity of presentation, the description that follows generally describes method  300  in the context of the system  100  illustrated in  FIG. 1 . However, it will be understood that method  300  may be performed, for example, by any other suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware as appropriate. 
     At  305 , an existing report is identified for migration. In some instances, users may specify a particular existing report for migration via a single generic service. The single generic service may be available via an enhanced UX application or system, such as SAP&#39;s FIORI UX application and environment. Each existing report may be associated with two parts—an existing set of metadata associated with a selection screen presented to users when attempting to execute the report and an existing set of report coding for execution of the report. The existing set of metadata can identify one or more parameters or attributes associated with the report, such as selectable fields used to filter or shape the report&#39;s execution and output. 
     In response to identifying the existing report, a new metadata object associated with the identified report is created at  310 . The new metadata object can be created in the UX system, in the existing backend system in which the existing report resides, or in any suitable location. At  315 , at least some of the existing metadata associated with the identified existing is replicated into the created metadata object. The replicated data may include a header or unique identifier, as well as a listing of one or more parameters associated with the report. 
     At  320 , at least one enhancement is received and incorporated into the created metadata object as a modification to the selection screen associated with the identified report. The at least one enhancement can include grouping one or more of the parameters associated with the report in the selection screen presentation, changing indention of the parameters, hiding one or more previously presented parameters in the enhanced selection screen, adding dependency relationships between two or more of the parameters, changing parameter presentation (e.g., names or labels), as well as others. Additionally, enhancements may include additional help exits for users to assist in completion of the selection screen input. For example, actions to be taken when a user activates a field or activates a “help” button, such as the “F4” button, may be added as an enhancement. This may include providing a data type to be input, information on a range of values to be input, or other information and/or functionality. Once the addition of the information is complete, at  325  the created metadata object is persisted for future execution. 
       FIG. 4  is an illustration of example operations for executing a report in the enhanced user experience environment based on the additional metadata layer and existing report functionality. For clarity of presentation, the description that follows generally describes method  400  in the context of the system  100  illustrated in  FIG. 1 . However, it will be understood that method  400  may be performed, for example, by any other suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware as appropriate. 
     At  405 , a request to execute a particular report is received. In some instances, the request can be received via a UX application or system, such as UX system  160 . At  410 , the previously created metadata object associated with the requested report is identified. In some instances, a gateway service may perform the operations associated with identifying the corresponding metadata object based on the association to the requested report. Further, the gateway service may combine or join the existing and newly created metadata for the UX application to use in generating the enhanced selection screen. 
     At  415 , an enhanced selection screen is presented based at least partly on the enhancements included in the metadata object as applied to the existing metadata of the existing report. The enhanced selection screen is rendered by the UX application and allows users to provide inputs for the one or more identified parameters. 
     At  420 , in response to receiving inputs at the presented selection screen, the inputs are passed to the coding associated with the existing report where the inputs are used to perform the operations associated with report. At  425 , the results of the report execution are generated. In some instances, this may include presentation of a result screen, completion or addition to a particular log or event database, or performance of one or more additional operations. 
       FIG. 8  is an illustration of an example swim lane diagram  800  associated with operations for executing a report in the enhanced user experience environment. For clarity of presentation, the description that follows generally describes diagram  800  in the context of the system  100  illustrated in  FIG. 1 . However, it will be understood that the operations of diagram  800  may be performed, for example, by any other suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware as appropriate. 
     As illustrated, an enhanced UX application—here, FIORI UI  805 —is used to call a previously enhanced selection screen and report based on a set of enhanced metadata stored in a metadata repository  820 . FIORI UI  805  requests the enhanced selection screen via gateway  810 , which delegates calls to backend system  815 . In some instances, one or more application exits may exist, such that additional operations associated with particular applications may be performed, where the application, or coding exits  825  are accessed by the backend system  815 . 
     At  830 , the FIORI UI  805  receives or determines a particular application and selection screen to be rendered. The FIORI UI  805  sends a request for the metadata corresponding to the enhanced selection screen to the gateway  810 . The gateway  810  converts the request and delegates the call to the backend system  815  at  832 . 
     At  834 , in response to the received request, the backend system  815  fetches the existing set of metadata and any enhanced metadata associated with the selection screen from the metadata repository  820 . This can include obtaining the original set of metadata plus accessing and retrieving the enhanced metadata from the corresponding metadata object, both of which may be located at the metadata repository  820 . In some instances, the existing set of metadata and the metadata object may be stored at different locations, as well as in different repositories. The two sets of metadata may be linked, for instance, by a header, unique identifier, or any other suitable connection such that the backend system  815  is able to access both sets of metadata. At  836 , the combined set of metadata is returned to the backend system  815  in response to its fetch operations. 
     In some instances, one or more coding exits  825  may exist that change the operation of the selection screen and the underlying application. The coding exits  825  may modify the operation of the selection screen, may alter parameters or values associated with the retrieved metadata, or may perform one or more dependency checks or other validations, among other actions. At  838 , and prior to returning the retrieved metadata from the metadata repository  820 , the backend system  815  can call to the coding exits  825  to determine if any particular application exits or modifications are to be performed. In some instances, the metadata itself may identify the particular application exits to be included or associated with a particular instance of the selection screen, such that the metadata itself triggers the call to the coding exits  825  when reviewed by the backend system  815 . If the metadata is changed in response to the coding exits  825 , the adjusted metadata is returned to the backend system  815  at  840 . 
     At  842 , the backend system  815  returns the complete set of metadata to the gateway  810 , where the gateway  810  can then prepare and return the metadata to the FIORI UI  805  at  844 . While not shown here, the FIORI UI  805  can then render the selection screen based on the previously enhanced metadata to provide the enhanced presentation as described herein. 
     At  846 , the FIORI UI  805  requests a set of default values associated with a particular entry in the selection screen, the request sent to the backend system  815  via gateway  810 , which relays the request, including an translation or transformation, at  848 . The backend system  815  retrieves, at  850 , the corresponding default values from the metadata repository  820 , which returns the appropriate values at  852 . Prior to returning the values to the FIORI UI  805  via the gateway  810 , the backend system  815  may determine whether one or more application exits should be called to adjust the default values. If necessary, at  854 , the application exits associated with the particular metadata and/or users accessing the selection screens are called from the coding exits  825  such that the default values are modified. For example, default values may be time or user-dependent, or the default values may be a specific value. Example default values may include the current date, the last seven days, or the organizational unit of the current user. Alternative values can be used to adjust those default values, or to make those values the default, as appropriate. At  856 , those modified values are returned to the backend system  815 , where the value changes are made. At  858 , the backend system  815  returns the default values (and any adjustments or modifications to those values) to the gateway  810 , which returns the adjusted values to the FIORI UI  805  at  860 . 
     At  862 , actions performed at the selection screen within the FIORI UI may cause additional checks and adjustments to be calculated in the values provided within the selection screen. For example, an explicit UI trigger may cause information to be updated, checked, revised, or otherwise processed. In other instances, user actions may cause specific triggers to occur, including completing a field in the selection screen, changing focus within the fields, or any other suitable action as defined by a rule set or the operations of the selection screen. The check triggered by the actions can include a verification of the data, data types, particular dependencies, and other checks associated with the data. The gateway  810  receives the triggered request to check the data and delegates a call to the backend system  815  to perform the checks. At  866 , the backend system  815  performs the checks associated with the selection screen. If necessitated by the backend system  815 , the metadata associated with the selection screen, or another reason, the backend system  815  can call application specific checks as needed at  868 , the coding exits  825  returning errors messages or adjusted data as necessary at  870 . At  872 , and in response to the checking of the inputs and any application-specific checks, the backend system  815  returns the adjusted data and/or any error or status messages provided during the checks to gateway  810 , which then returns that information to the FIORI UI  805  at  874 . 
     Described implementations of the subject matter can include one or more features, alone or in combination. 
     For example, in a first implementation, a computer-implemented method includes identifying an existing report for migration to an enhanced user experience application, the existing report associated with a set of existing metadata for selection screen presentation of the existing report and backend coding for execution of the existing report; creating a metadata object associated with the identified report; replicating at least some of the existing metadata associated with the identified existing report into the created metadata object; receiving at least one enhancement to the created metadata object, the at least one enhancement including at least one additional metadata attribute to be represented in an updated selection screen presentation associated with the enhanced user experience application; and persisting the created metadata object for later execution. 
     The foregoing and other described implementations can each optionally include one or more of the following features: 
     A first feature, combinable with any of the following features, further comprising receiving a request to execute the identified report in the enhanced user experience application; identifying the created metadata object associated with the particular report; present the updated selection screen based at least partly on the identified metadata object, the updated selection screen presentation including the at least one enhancement of the created metadata object applied to the existing metadata associated with the existing report; and executing the identified report based on input received via the updated selection screen, wherein executing the identified report comprises using the backend coding for execution. 
     A second feature, combinable with any of the previous or following features, wherein the backend coding for execution comprises the backend coding associated with the existing report. 
     A third feature, combinable with any of the previous or following features, wherein the metadata object is associated with the identified report based on a header corresponding to the name of the identified report. 
     A fourth feature, combinable with any of the previous or following features, wherein the operations are performed by a generic service operable to migrate any existing report to the enhanced user experience application. 
     A fifth feature, combinable with any of the previous or following features, wherein replicating at least some of the existing metadata associated with the identified existing report into the created metadata object comprises identifying a set of parameters associated with the existing report; and incorporating at least a portion of the identified set of parameters into the created metadata object. 
     A sixth feature, combinable with any of the previous or following features, wherein the at least one additional metadata attribute includes layout information associated with the updated selection screen presentation, a determination of one or more mandatory fields within the updated selection screen presentation, a grouping of fields within the updated selection screen presentation, and dependency information between at least two fields in the updated selection screen presentation. 
     A seventh feature, combinable with any of the previous or following features, wherein the at least one additional metadata attribute includes a set of coding value help information, the coding value help information identifying a range or type of value information associated with at least one field included in the updated selection screen presentation. 
     An eighth feature, combinable with any of the previous or following features, wherein the existing report is associated with a legacy system. 
     A ninth feature, combinable with any of the previous or following features, wherein the created metadata object is persisted in the same location as the existing report. 
     In a second implementation, a computer program product comprising computer-readable instructions, which, when loaded and executed on a computer system, cause the computer system to perform operations comprising: identifying an existing report for migration to an enhanced user experience application, the existing report associated with a set of existing metadata for selection screen presentation of the existing report and backend coding for execution of the existing report; creating a metadata object associated with the identified report; replicating at least some of the existing metadata associated with the identified existing report into the created metadata object; receiving at least one enhancement to the created metadata object, the at least one enhancement including at least one additional metadata attribute to be represented in an updated selection screen presentation associated with the enhanced user experience application; and persisting the created metadata object for later execution. 
     The foregoing and other described implementations can each optionally include one or more of the following features: 
     A first feature, combinable with any of the following features, further comprising receiving a request to execute the identified report in the enhanced user experience application; identifying the created metadata object associated with the particular report; present the updated selection screen based at least partly on the identified metadata object, the updated selection screen presentation including the at least one enhancement of the created metadata object applied to the existing metadata associated with the existing report; and executing the identified report based on input received via the updated selection screen, wherein executing the identified report comprises using the backend coding for execution. 
     A second feature, combinable with any of the previous or following features, wherein the backend coding for execution comprises the backend coding associated with the existing report. 
     A third feature, combinable with any of the previous or following features, wherein the metadata object is associated with the identified report based on a header corresponding to the name of the identified report. 
     A fourth feature, combinable with any of the previous or following features, wherein the operations are performed by a generic service operable to migrate any existing report to the enhanced user experience application. 
     A fifth feature, combinable with any of the previous or following features, wherein replicating at least some of the existing metadata associated with the identified existing report into the created metadata object comprises identifying a set of parameters associated with the existing report; and incorporating at least a portion of the identified set of parameters into the created metadata object. 
     A sixth feature, combinable with any of the previous or following features, wherein the at least one additional metadata attribute includes layout information associated with the updated selection screen presentation, a determination of one or more mandatory fields within the updated selection screen presentation, a grouping of fields within the updated selection screen presentation, and dependency information between at least two fields in the updated selection screen presentation. 
     A seventh feature, combinable with any of the previous or following features, wherein the at least one additional metadata attribute includes a set of coding value help information, the coding value help information identifying a range or type of value information associated with at least one field included in the updated selection screen presentation. 
     An eighth feature, combinable with any of the previous or following features, wherein the existing report is associated with a legacy system. 
     A ninth feature, combinable with any of the previous or following features, wherein the created metadata object is persisted in the same location as the existing report. 
     In some implementations, the computer program product can be implemented on a non-transitory, computer-readable medium storing one or more instructions executable by a computer system to perform the above-described operations. 
     In a third implementation, a computer system, comprising: a computer memory; and a hardware processor interoperably coupled with the computer memory and configured to perform operations comprising: identifying an existing report for migration to an enhanced user experience application, the existing report associated with a set of existing metadata for selection screen presentation of the existing report and backend coding for execution of the existing report; creating a metadata object associated with the identified report; replicating at least some of the existing metadata associated with the identified existing report into the created metadata object; receiving at least one enhancement to the created metadata object, the at least one enhancement including at least one additional metadata attribute to be represented in an updated selection screen presentation associated with the enhanced user experience application; and persisting the created metadata object for later execution. 
     The foregoing and other described implementations can each optionally include one or more of the following features: 
     A first feature, combinable with any of the following features, further comprising receiving a request to execute the identified report in the enhanced user experience application; identifying the created metadata object associated with the particular report; present the updated selection screen based at least partly on the identified metadata object, the updated selection screen presentation including the at least one enhancement of the created metadata object applied to the existing metadata associated with the existing report; and executing the identified report based on input received via the updated selection screen, wherein executing the identified report comprises using the backend coding for execution. 
     A second feature, combinable with any of the previous or following features, wherein the backend coding for execution comprises the backend coding associated with the existing report. 
     A third feature, combinable with any of the previous or following features, wherein the metadata object is associated with the identified report based on a header corresponding to the name of the identified report. 
     A fourth feature, combinable with any of the previous or following features, wherein the operations are performed by a generic service operable to migrate any existing report to the enhanced user experience application. 
     A fifth feature, combinable with any of the previous or following features, wherein replicating at least some of the existing metadata associated with the identified existing report into the created metadata object comprises identifying a set of parameters associated with the existing report; and incorporating at least a portion of the identified set of parameters into the created metadata object. 
     A sixth feature, combinable with any of the previous or following features, wherein the at least one additional metadata attribute includes layout information associated with the updated selection screen presentation, a determination of one or more mandatory fields within the updated selection screen presentation, a grouping of fields within the updated selection screen presentation, and dependency information between at least two fields in the updated selection screen presentation. 
     A seventh feature, combinable with any of the previous or following features, wherein the at least one additional metadata attribute includes a set of coding value help information, the coding value help information identifying a range or type of value information associated with at least one field included in the updated selection screen presentation. 
     An eighth feature, combinable with any of the previous or following features, wherein the existing report is associated with a legacy system. 
     A ninth feature, combinable with any of the previous or following features, wherein the created metadata object is persisted in the same location as the existing report. 
     The preceding figures and accompanying description illustrate example processes and computer implementable techniques. But environment  100  (or its software or other components) contemplates using, implementing, or executing any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any appropriate time, including concurrently, individually, or in combination. In addition, many of the steps in these processes may take place simultaneously, concurrently, and/or in different orders than as shown. Moreover, environment  100  may use processes with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate. 
     In other words, although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.