WO2022010491A1 - Commutation de version d'application - Google Patents

Commutation de version d'application Download PDF

Info

Publication number
WO2022010491A1
WO2022010491A1 PCT/US2020/041614 US2020041614W WO2022010491A1 WO 2022010491 A1 WO2022010491 A1 WO 2022010491A1 US 2020041614 W US2020041614 W US 2020041614W WO 2022010491 A1 WO2022010491 A1 WO 2022010491A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
version
engine
indication
execute
Prior art date
Application number
PCT/US2020/041614
Other languages
English (en)
Inventor
Mauricio COUTINHO MORAES
Jhonny Marcos Acordi MERTZ
Patrick Ucker CALVETTI
Original Assignee
Hewlett-Packard Development Company, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2020/041614 priority Critical patent/WO2022010491A1/fr
Publication of WO2022010491A1 publication Critical patent/WO2022010491A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions

Definitions

  • Feature switching is sometimes performed using toggling to toggle features on and off, for example at websites and/or other types of applications. For example, particular subsets of code may be enabled or disabled to toggle the features on and off.
  • Figure 1 is a block diagram of an example system to implement application version switching.
  • Figure 2 is a block diagram of another example system to implement application version switching.
  • Figure 3 is a flow diagram of an example method to implement application version switching.
  • Figure 4 is a block diagram of an example computer-readable medium including instructions that causes a processor to implement application version switching.
  • Figure 5 is an example of a first version of an application.
  • Figure 6 is an example of a second version of the application of Figure 5.
  • Figure 7 is an example of an application engine to execute different versions of an application.
  • Figure 8 is another example of an application engine to execute different versions of an application.
  • Figure 9 is an example sequence diagram showing components of the system of Figure 2 implementing application version switching. DETAILED DESCRIPTION
  • Feature switching is sometimes performed using toggling to toggle features on and off, for example at websites and/or other types of applications. For example, particular subsets of code may be enabled or disabled to toggle the features on and off.
  • Feature switching may be implemented manually to modify code to include feature toggles and/or version toggles, which is generally inefficient, and is often done on a feature by feature basis.
  • a system which modifies an application engine as different versions of an application are produced.
  • the different versions may be switched and/or toggled to execute the different versions of the application as controlled, for example, by toggle engines (which for example, may determine which version of the application to be executed based on configuration data and/or context data, such as a geographic location from which a request for the application was received, and the like).
  • the different versions of the application may be determined via a version history (e.g. as stored at a version history database, and the like) and the application engine may be modified to include a command that retrieves an indication of which version of the application to execute (e.g. such as a version number, and the like).
  • the application engine may be modified to include commands to call the version of the application specified by the indication, and/or the application engine may be modified to include respective code segments of versions of the application, as indicated by the version history, the respective code segments executed based on the indication.
  • application engine may be modified in any suitable manner to execute the different versions of the application as indicated by the indication.
  • an aspect of the present specification is directed to a system comprising: an application engine to: execute an application; a version history engine to: access a version history of the application; and an application modification engine to modify the application engine according to the version history, to cause the application engine to: determine an indication of a version of the application to execute as indicated by the version history; and execute the version of the application specified by the indication.
  • Another aspect of the present specification is directed to a method comprising: receiving, at a computing device, an execution command to execute an application having a plurality of versions identified by respective indications; determining, at the computing device, an indication of a version of the application to execute based on: context data of the execution command; and version configuration data determined using the context data; and executing, at the computing device, an application engine automatically modified, using a version history of the application, to: execute the version of the application specified by the indication.
  • Another aspect of the present specification is directed to a non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to: execute an application module; execute a version history module to: access a version history of the application; and execute an application modification module to modify the application module according to the version history to cause the processor, when executing the application module to: determine an indication of a version of the application to execute as indicated by the version history.
  • FIG. 1 is a block diagram of an example system 100 to implement application version switching.
  • the system 100 includes an application engine 111 , a version history engine 113 and an application modification engine 115. Communication between components and/or engines described herein is shown in the figures of the present specification as arrows therebetween.
  • the term “engine” refers to hardware (e.g., a processor, such as a central processing unit (CPU) an integrated circuit or other circuitry) or a combination of hardware and software (e.g., programming such as machine- or processor-executable instructions, commands, or code such as firmware, a device driver, programming, object code, etc. as stored on hardware).
  • Hardware includes a hardware element with no software elements such as an application specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), etc.
  • a combination of hardware and software includes software hosted at hardware (e.g., a software module that is stored at a processor-readable memory such as random access memory (RAM), a hard disk or solid-state drive, resistive memory, or optical media such as a digital versatile disc (DVD), and/or implemented or interpreted by a processor), or hardware and software hosted at hardware.
  • software hosted at hardware e.g., a software module that is stored at a processor-readable memory such as random access memory (RAM), a hard disk or solid-state drive, resistive memory, or optical media such as a digital versatile disc (DVD), and/or implemented or interpreted by a processor
  • hardware e.g., a software module that is stored at a processor-readable memory such as random access memory (RAM), a hard disk or solid-state drive, resistive memory, or optical media such as a digital versatile disc (DVD), and/or implemented or interpreted by a processor
  • the application engine 111 may comprise hardware or a combination of software and hardware for implementing functionality to: implement an application, such as a website, and the like, however the application engine 111 may be to implement any suitable application.
  • the application engine 111 may comprise a portion of a server and/or computing device which hosts the application engine 111.
  • the application engine 111 may comprise hardware or a combination of software and hardware of any suitable server and/or computing device and/or more than one suitable server and/or computing device.
  • the application engine 111 may comprise code segments to implement the application, the code segments comprising portions and/or segments of code and/or source code and/or executable instructions executed when the application engine 111 is implemented, and the like.
  • the application engine 111 is to execute one version of an application, for example an initial version of the application.
  • developers may generally update the application to newer versions, for example to add features and/or fix issues (e.g. bugs), and the like.
  • the system 100 further comprises a version history engine 113 to access a version history (not depicted) of the application, for example at a memory or a database storing versions of the application.
  • a memory and/or database may comprise an enterprise memory and/or an enterprise database (e.g. of an enterprise providing the application and to which developers who work for the enterprise may submit versions of the application) and/or a public memory and/or public database (e.g. to which anyone may submit versions of the application, for example in an open source environment).
  • the version history engine 113 may be to determine when a different version of the application has been stored at, and/or uploaded to, the memory and/or database.
  • the version history engine 113 may be to periodically query a version history memory and/or database for version history updates, and/or a version history memory and/or database (and/or a computing device thereof) may be to notify the application modification engine 113 of version history updates when another version of the application is stored at, and/or uploaded to, the version history memory and/or database.
  • the version history engine 113 may be to: access the version history of the application as the version history is updated with newer versions of the application.
  • the system 100 further comprises the application modification engine 115 to modify the application engine 111 according to the version history.
  • the version history engine 113 may determine when another version of the application has been added to the memory and/or database and alert the application modification engine 115 thereto.
  • the functionality of the version history engine 113 may be combined with the application modification engine 115.
  • the application modification engine 115 is generally to modify the application engine 111 according to the version history to cause the application engine 111 to: determine an indication of a version of the application to execute as indicated by the version history; and execute the version of the application specified by the indication.
  • the application modification engine 115 may modify the application engine 111 to cause the application engine 111 to determine the indication of the version of the application to execute by: modifying the application engine 111 (e.g. modify and/or add to code segments of the application engine 111) to include a command to retrieve the indication.
  • the indication may be determined by run-time components and/or engines at a time of execution of the application engine 111 (e.g. at a run-time of the application), described in more detail below; the command may be used to retrieve the indication (e.g. from the run-time components) to assist the application engine 111 in determining which version of the application to execute at run-time.
  • the application modification engine 115 may insert, into the application engine, prior to code segments to execute the version of the application, a command to retrieve the indication when executing the application.
  • the application modification engine 115 may modify the application engine 111 (e.g. modify and/or add to code segments of the application engine 111) to cause the application engine 111 to execute the version of the application specified by the indication by: modifying the application engine 111 to include commands to call the version of the application specified by the indication.
  • the application modification engine 115 may be further to: generate a plurality of application files and/or functions according to the version history, the plurality of application files and/or functions identified by respective distinct names associated with respective indications; and modify the application engine 111 according to the version history by incorporating the respective distinct names into the application engine 111 such that the application engine 111 calls an application file and/or function according to the indication associated with a respective distinct name thereof.
  • the application files and/or functions may be named according to a version thereof (e.g. “App_V1”, “App_V2”, for two versions of an application) and incorporated into the application engine 111 and/or stored at a memory accessible to the application engine 111.
  • the application engine 111 may call the determined version of the application by calling the associated named application file and/or function; for example, when a “Version 2” of the application is to be executed, the application engine 111 may call the application file and/or function that represents “Version 2” with the associated name.
  • the application modification engine 115 may be to modify the application engine 111 according to the version history, to cause the application engine 111 to execute the version of the application specified by the indication by: modifying the application engine 111 to include respective code segments of versions of the application, as indicated by the version history, the respective code segments executed based on the indication.
  • the application modification engine 115 may be to incorporate code segments associated with the versions of the application into the application engine 111 , the code segments identified in the application engine 111 , by respective indications associated with the versions of the application, such that the code segments identified by the indication are executed by the application engine 111 and the code segments identified by remaining respective indications are refrained from being executed.
  • the application modification engine 115 may insert, into the application engine 111 , “IF/ELSE” sets of commands and/or code segments and the like, which specify that “IF” the indication indicates a first version of the application, then the application engine 111 is to execute code segments of the first version of the application, which are also incorporated into the application engine 111 (e.g.
  • the application modification engine 115 modifies the application engine 111 in any suitable manner according to the version history of the application as updated (e.g. in response to the version history of the being updated with newer versions of the application, as determined by the version history engine 113).
  • Figure 2 is a block diagram of another example system 200 to implement application version switching.
  • the system 200 is substantially similar to the system 100, with like components having like numbers, but in a “200” series rather than a “100” series.
  • the system 200 may include an application engine 211 , a version history engine 213 and an application modification engine 215 which are respectively substantially similar to the application engine 111 , the version history engine 113 and the application modification engine 115.
  • the system 200 further includes a version history memory and/or database 217 (interchangeably referred to hereafter as the database 217) storing two example versions 219-1 , 219-2 of an application (e.g. “APP_V1”, and “APP_V2”) to be executed by the application engine 211 and which is accessible by the version history engine 213 and the application modification engine 215.
  • the versions 219-1 , 219-2 are interchangeably referred to hereafter, collectively, as the versions 219 and, generically, as a version 219. While two versions 219 are shown, the database 217 may store any suitable number of versions 219 named in any suitable manner; a number of the versions 219 may change (e.g. increase) as versions 219 are added to the database 217; however, the number of the versions 219 may decrease, when versions 219 are deleted from the database 217.
  • the version history engine 213 may access the database 217 to determine when new versions 219 of the application are added, and notify the application modification engine 215 accordingly, and the application modification engine 215 may modify the application engine 211 accordingly.
  • the application engine 211 comprises code segments 221 which the application modification engine 215 may modify and/or to which the application modification engine 215 may add. It is understood that the version history engine 213 may access the database 217 to determine when versions 219 of the application are deleted, and notify the application modification engine 215 accordingly, and the application modification engine 215 may modify the code segments 221 and/or the application engine 211 accordingly.
  • the system 200 further comprises run-time components, in particular a toggle engine 231 , a context builder engine 233, and a version determination engine 235 which, at a run-time of the application engine 211 , may determine which version 219 of the application the application engine 211 is to execute. While the run-time components are depicted as being separate, in other examples, functionality of the toggle engine 231 and/or the context builder engine 233 and/or the version determination engine 235 may be combined into one engine and/or more than one engine.
  • the application engine 211 may receive, from a communication device 241 an execution command to execute an application having a plurality of versions 219 identified by respective indications for the application represented by the versions 219 (e.g. a webpage and the like).
  • the communication device 241 may comprise a communication device of a user who operates the communication device 241 to request webpages, and the like.
  • the application engine 211 may call and/or communicate with the toggle engine 231 to determine an indication of a version 219 of the application to be implemented for example using the version determination engine 235, as described hereafter.
  • the toggle engine 231 , the context builder engine 233 and the version determination engine 235 may communicate to determine which version 219 of the application is to be executed, generate an indication thereof, and provide the indication to the application engine 211 , which executes the associated version 219, and provides a response to the communication device 241.
  • the toggle engine 231 , the context builder engine 233 and the version determination engine 235 may determine which version 219 of the application is to be executed based on: context data of the execution command; and version configuration data determined using the context data.
  • the toggle engine 231 may determine the context data of the execution command by communicating with the context builder engine 233 which may determine, for example, a geographic location from which the execution command originated (e.g.
  • the context builder engine 233 may hence be to receive the context data and/or header data and/or metadata and determine context thereof, including, but not limited to, a geographic location associated with a network address, and the like.
  • Such context data may be communicated, by the toggle engine 231 , to the version determination engine 235 which may communicate with a configuration database 251 storing version configuration data 253.
  • the version configuration data may associate context data to versions 219 of the applications. For example, a first geographic location (e.g. as indicated by the context data) may be associated with the first version 219-1 of the application, and a second geographic location (e.g.
  • the application engine 211 may be forced to implement the first version 219-1 of the application, and/or when the communication device 241 is located in the second geographic location, the application engine 211 may be forced to implement the second version 219-2 of the application.
  • different locations and/or jurisdictions may enforce different requirements for applications, such as websites, and the versions 219 may reflect such requirements, and the requirements may be indicated by the version configuration data 253.
  • the version configuration data 253 may be generated and/or updated by an administrator of the system 200 and/or the version configuration data 253 may be generated and/or updated automatically and/or electronically by any suitable component of the system 200, for example when new versions 219 of the application are stored at the database 217; hence, while not depicted, the configuration database 251 may be in communication with other components of the system 200 which may update the version configuration data 253 (e.g. such as the version history engine 213) as versions 219 of the application are stored and/or changed at the database 217.
  • the version configuration data 253 e.g. such as the version history engine 213
  • the version determination engine 235 may use the context data to search and/or query the configuration database 251 for configuration data which may enable the version determination engine 235 to determine an indication of the version 219 of the application to execute based on the context data, which is returned to the application engine 211 via the toggle engine 231.
  • method 300 may be performed with the system 200, and at least partially by a computing device implementing the system 200 and/or a processor thereof. Indeed, the method 300 may be one way in which the system 200 may be configured. Furthermore, the following discussion of method 300 may lead to a further understanding of the system 200, and its various components. Furthermore, it is to be emphasized, that method 300 may not be performed in the exact sequence as shown, and various blocks may be performed in parallel rather than in sequence, or in a different sequence altogether. Furthermore, it is to be emphasized that the method 300 may alternatively be performed with the system 100, and at least partially by a computing device implementing the system 100 and/or a processor thereof.
  • a computing device receives an execution command to execute an application having a plurality of versions 219 identified by respective indications. For example, as described above, a computing device executing the application engine 211 receives an execution command from the communication device 241.
  • the computing device determines an indication of a version 219 of the application to execute based on: context data of the execution command (as described above); and version configuration data determined and/or queried using the context data.
  • the toggle engine 231 and/or the context builder engine 233 is hence understood to have access to, for example, header data and/or metadata of the execution command in order to determine the context data.
  • the application engine 211 may pass the execution command and/or the header data and/or the metadata thereof to the toggle engine 231 , which may pass the execution command and/or the header data and/or the metadata thereof to the context builder engine 233; and/or the execution command and/or the header data and/or the metadata thereof may be at least temporarily stored in a memory accessible to suitable components of the system 200.
  • the context builder engine 233 may then return the context data to the toggle engine 231 , which passes the context data to the version determination engine 235.
  • the context data is used to query the configuration database 251 (e.g. via the version determination engine 235) to determine which version 219 of the application to execute based on the version configuration data 253.
  • a set of the version configuration data 253 which indicates which version 219 of the application to execute may be selected based on the context data.
  • the context data includes collisions between versions 219 of the application to be executed (e.g. a geographic location of the execution command may indicate that the first version 219-1 of the application is to be executed, but the execution command may request the second version 219-2)
  • the version configuration data 253 may indicate which context data is to be given priority (e.g.
  • the method 300 may include the computing device determining the context data of the execution command by communicating with the context builder engine 233.
  • the method 300 may include the computing device: communicating (e.g. via the version determination engine 235) the context data to the configuration database 251 storing the version configuration data 253; and receiving, from the configuration database 251 (e.g. via the version determination engine 235), the indication of the version 219 of the application to execute.
  • the indication may comprise a version number of the application to execute, however the indication may comprise any suitable indicator of a version 219 of the application to execute.
  • the computing device may determine, at the block 303, the indication of the version 219 of the application to execute by executing the version determination engine 235.
  • the computing device executes the application engine 211 which, as described herein, has been automatically and/or electronically modified, using a version history of the application, to: execute the version 219 of the application specified by the indication.
  • the toggle engine 231 may communicate the indication to the application engine 211 , which executes the associated version 219 accordingly, and/or the indication may be stored at a memory accessible to the toggle engine 231 and the application engine 211) and which may be retrieved by the application engine 211 to determine the version 219 of the application to be executed.
  • Figure 4 is a block diagram of an example device 400 that includes a computer-readable medium 401 and a processor 402.
  • the computer-readable medium 401 includes instructions that, when implemented by the processor 402, cause the processor 402 to implement application version switching.
  • the computer-readable medium 401 may be a non-transitory computer- readable medium, such as a volatile computer-readable medium (e.g., volatile RAM, a processor cache, a processor register, etc.), a non-volatile computer- readable medium (e.g., a magnetic storage device, an optical storage device, a paper storage device, flash memory, read-only memory, non-volatile RAM, etc.), and/or the like.
  • a volatile computer-readable medium e.g., volatile RAM, a processor cache, a processor register, etc.
  • a non-volatile computer- readable medium e.g., a magnetic storage device, an optical storage device, a paper storage device, flash memory, read-only memory, non-volatile RAM, etc.
  • the processor 402 may be a general-purpose processor or special purpose logic, such as a microprocessor (e.g., a central processing unit, a graphics processing unit, etc.), a digital signal processor, a microcontroller, an ASIC, an FPGA, a PAL (programmable array logic), a PLA (programmable logic array), a PLD (programmable logic device), etc.
  • a microprocessor e.g., a central processing unit, a graphics processing unit, etc.
  • ASIC an FPGA
  • PAL programmable array logic
  • PLA programmable logic array
  • PLD programmable logic device
  • the computer-readable medium 401 includes modules.
  • a “module” (in some examples referred to as a “software module”) is a set of instructions that when implemented or interpreted by a processor or stored at a processor-readable medium realizes a component or performs a method.
  • the computer-readable medium 401 includes various modules which correspond to functionality of the engines of the system 200.
  • the computer-readable medium 401 includes an application module 411 , which, when processed by the processor 402, may provide the processor 402 with functionality similar to the application engine 211.
  • the application module 411 may cause the processor 402 to execute an application.
  • the computer-readable medium 401 includes a version history module 413, which, when processed by the processor 402, may provide the processor 402 with functionality similar to the version history engine 213.
  • the version history module 413 may cause the processor 402 to access a version history of the application.
  • the computer readable medium 401 further stores the version history database 217, however the database 217 may be stored in a different location and/or memory.
  • the computer-readable medium 401 includes an application modification module 415, which, when processed by the processor 402, may provide the processor 402 with functionality similar to the application modification engine 215.
  • the application modification module 415 may cause the processor 402 to modify the application module 411 according to the version history to cause processor 402, when executing the application module 411 , to: determine an indication of a version 219 of the application to execute as indicated by the version history.
  • the version history module 413 may be to further cause the processor 402 to: access the version history of the application as the version history is updated with newer versions 219 of the application, as described above.
  • the application modification module 415 may be to further cause the processor 402 to: modify the application module 411 according to the version history as updated, as also described above.
  • the application modification module 415 may be to further cause the processor 402 to: generate a plurality of application files according to the version history, the plurality of application files identified by respective distinct names associated with respective indications; and modify the application module 411 according to the version history by incorporating the respective distinct names into the application module 411 such that the processor 402, when executing the application module 411 , calls an application file according to the indication associated with a respective distinct name thereof.
  • the application modification module 415 may be to further cause the processor 402 to modify the application module 411 according to the version history to cause processor, when executing the application module 411 , to determine the indication of the version 219 of the application to execute as indicated by the version history by: inserting, into the application module 411 , prior to code segments to execute the version 219 of the application, a command to retrieve the indication when executing the application.
  • the application modification module 415 may be to further cause the processor 402 to modify the application module 411 according to the version history by: incorporating code segments associated with the versions 219 of the application into the application module 411 , the code segments identified in the application module 411 , by respective indications associated with the versions 219 of the application, such that the code segments identified by the indication are executed by processor 402 when executing the application module 411 and the code segments identified by remaining respective indications are refrained from being executed.
  • the computer-readable medium 401 includes a toggle module 431 , a context builder module 433, and a version determination module 435, which, when processed by the processor 402, may respectively provide the processor 402 with functionality similar to the toggle engine 231 , the context builder engine 233, and the version determination engine 235. As depicted, the computer-readable medium 401 further stores the configuration database 251 .
  • the modules 431 , 433, 435 and/or the configuration database 251 may be stored at a different computing device from the modules 411 , 413, 415 and/or the database 217; for example the modules 411 , 413, 415 and/or the database 217 may be stored at the device 400 which implements version updating and application execution components of the system 200, and the modules 431 , 433, 435 and/or the configuration database 251 may be stored at another computing device which implements run-time components of the system 200.
  • Figure 5 and Figure 6 respectively depict code segments of two versions 219-1 , 219-2 of an application and in particular a function “handleRequest”.
  • Figure 5 and Figure 6 depict a code snippets in Javascript-like code.
  • Various functions, and other parts of the code snippets are on various lines indicated by line numbering 01 , 02, 03, etc.
  • the function “handleRequest” may be annotated with the annotation “@VersionToggle” having a toggle name of “RequestHandle”, which may be defined in a Javascript-like class skeleton (not depicted).
  • the versions 219 have a same class and a same name, they are understood to be different versions of a same application which the system 200 (and the like) may toggle between.
  • the two versions 219 of the application of Figure 5 and Figure 6 generally performs an authorization of a user based on a string “user” received, along with an integer “input”, for example in an execution command, such a request to process the application engine 111 , the application engine 211 and/or the application module 411 , as received from the communication device 241 , and the like.
  • the two versions 219 of the application of Figure 5 and Figure 6 performs an authorization of the “user” for example by determining whether the “user” has access to a given function “businessLogic” (e.g. on line 07), for example as indicated in a database, and the like. Such a determination is made via a function “!hasAccess(user)”).
  • businessLogic e.g. on line 07
  • the version 219-1 determines whether the “input” is valid via a function “!isValid(input)”. If the “input” is not valid, an error code “400” is returned. If the “input” is valid, the function “business logic( user, input)” is implemented and a code “200” is returned.
  • the version 219-2 provides similar functionality but differs from the version 219-1 as next described.
  • the version 219-2 determines whether the “input” is valid via a function “!islnputValid(input)”, which is different from the function “!isValid(input)” of the version 219-1 , and which may be more accurate and/or less prone to error than the function “!isValid(input)”. If the “input” is not valid, an error code “400” is returned as well as a message “invalid”. If the “input” is valid, the function “business logic( user, input)” is implemented and a code “200” is returned.
  • the two versions 219 provide similar functionality, but the version 219-2 provides error messages (e.g. “unauthorized” and “invalid”) as well as determines whether the “input” is valid via a function that is different from a function of the version 219-1.
  • error messages e.g. “unauthorized” and “invalid”
  • the application engine 211 may initially comprise the version 219- 1 (but without the annotation on line 01 and/or a different annotation). Put another way, the code segments 221 of the application engine 211 may initially comprise the code segments of Figure 5.
  • the application modification engine 215 may modify the application engine 211 and/or the code segments 221 thereof as depicted in Figure 7 or Figure 8 to implement a particular version 219 of an application, depending on an indication.
  • the application engine 211 has been modified to remove specific code segments of either of the versions 219 of Figure 5 and Figure 6, other than the function name “handleRequest” and the fields for receiving “user” and “input, and replaced with a command “getVersionToToggle ()” which retrieves, for example from a memory and/or the toggle engine 231 , the indication of which version 219 of the application to execute.
  • the command “getVersionToToggle ()” may pass the execution command and/or header data and/or metadata thereof to the toggle engine 231 as described herein.
  • the execution command and/or header data and/or metadata thereof may be used as input to the function getVersionToToggle().
  • the indication retrieved may be “1” for the version 219-1 of Figure 5, or “2” for the version 219-2 of Figure 6.
  • the variable “versionToToggle” is set to the indication, and an if/else set of commands is used to pass the indication to one of a plurality of application files identified by respective distinct names associated with respective indications.
  • the application modification engine 215 has generated an application file (and/or function) named “handleRequest_V1” comprising the version 219-1 depicted in Figure 5, and has further generated an application file and/or function) named “handleRequest_V2” comprising the version 219-2 depicted in Figure 6.
  • the application files and/or functions “handleRequest_V1”, “handleRequest_V2” may be stored in a memory accessible to the application engine 211 and/or may be components of the application engine 211.
  • the application files and/or functions “handleRequest_V1”, “handleRequest_V2” receive, as input, the strings “user” and “input”.
  • the if/else set of commands causes the application file and/or function named “handleRequest_V1” to be executed and/or called when the indication is “1”, and the if/else set of commands causes the application file and/or function named “handleRequest_V2” to be executed and/or called when the indication is
  • the application modification engine 215 may modify the application engine 211 to call an application file and/or function named “handleRequest_V3”, and the like, to be executed and/or called when the indication (e.g. versionToToggle) is “3”.
  • Figure 8 depicts the application engine 211 , and code segments 221 thereof, as modified by the application modification engine 215 in other examples.
  • the application engine 211 again includes the function “getVersionToToggle()” which returns the indication of the version 219 of the application to implement.
  • the application modification engine 215 has incorporated the code segments of the versions 219-1 , 219-2 as depicted in Figure 5 and Figure 6, into the application engine 211 , which are selected using if/else sets of commands.
  • the application modification engine 215 may modify the application engine 211 to include respective code segments thereof which are executed and/or called when the indication (e.g. versionToToggle) is “3”.
  • the application modification engine 215 may modify the application engine 211 and/or the code segments 221 thereof as depicted in Figure 7 and/or Figure 8 depending on a configuration thereof and/or settings by a system administrator.
  • the example of Figure 7 is simpler than the example of Figure 8, the example of Figure 7 uses more function calls (e.g. functions “handleRequest_V1”, “handleRequest_V2” are called which, in turn call functions) than the example of Figure 8 (and hence may use more processing resources to implement at run-time).
  • the example of Figure 7 may be simpler to generate then the example of Figure 8.
  • the application modification engine 215 may be further to determine which of the examples to implement based, for example, on complexity of generation and/or error checking (which may be based on complexity of the original applications (e.g. applications 219) and/or an evaluation of respective processing resources used to implement the respective examples of Figure 7 and Figure 8 (e.g. which may be based on numbers of function calls, and/or any other suitable parameter).
  • complexity of generation and/or error checking which may be based on complexity of the original applications (e.g. applications 219) and/or an evaluation of respective processing resources used to implement the respective examples of Figure 7 and Figure 8 (e.g. which may be based on numbers of function calls, and/or any other suitable parameter).
  • Figure 9 is an example sequence diagram 900 showing components of the system of Figure 2 implementing application version switching at a run-time of the application engine 211. It is understood in Figure 9 that the application engine 211 has been modified to implement different versions of an application depending on an indication of version of the application to be determined. Hence, for example, in Figure 9, the application engine 211 may be modified similar to Figure 7 or Figure 8.
  • the communication device 241 transmits an execution command 901 to the application engine 211 which communicates the execution command 901 , and/or header data and/or metadata thereof, to the toggle engine 231 (e.g. which may occur via the application engine 211 implementing the “getVersionToToggle ()” function).
  • the toggle engine 231 transmits a request 903 for context data to the context builder engine 233; the request 903 may include the execution command and/or header data and/or metadata thereof.
  • the context builder engine 233 returns context data 905, as described above (e.g. a geographic location from which the execution command was received, for example as indicated by a network address of the execution command and/or header data and/or metadata thereof).
  • the toggle engine 231 receives the context data 905 and transmits the context data 905 to the version determination engine 235.
  • the version determination engine 235 may use the context data 905 to read and/or query 907 the configuration database 251 (which may occur via a suitable computing device, which may also be referred to as a “connector” and the like) to receive configuration data 909, which is used, by the version determination engine 235 to determine an indication 911 of which version 219 of the application is to be executed.
  • the version determination engine 235 returns the indication 911 to the toggle engine 231 , which returns the indication 911 to the application engine 211.
  • the application engine 211 executes 913 the version 219 of the application indicated by the indication 911 to return a response 915 to the communication device 241.
  • the application engine 211 may be automatically and/or electronically adapted to automatically toggle between different versions of an application.
  • the application engine 211 may be automatically and/or electronically adapted to automatically toggle between different versions of an application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Un système donné à titre d'exemple comprend un moteur d'application permettant d'exécuter une application. Le système donné à titre d'exemple comprend un moteur d'historique de version permettant d'accéder à un historique de version de l'application. Le système donné à titre d'exemple comprend un moteur de modification d'application pour modifier le moteur d'application en fonction de l'historique de version, pour amener le moteur d'application : à déterminer une indication d'une version de l'application à exécuter comme indiqué par l'historique de version ; et à exécuter la version de l'application spécifiée par l'indication.
PCT/US2020/041614 2020-07-10 2020-07-10 Commutation de version d'application WO2022010491A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2020/041614 WO2022010491A1 (fr) 2020-07-10 2020-07-10 Commutation de version d'application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/041614 WO2022010491A1 (fr) 2020-07-10 2020-07-10 Commutation de version d'application

Publications (1)

Publication Number Publication Date
WO2022010491A1 true WO2022010491A1 (fr) 2022-01-13

Family

ID=79552703

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/041614 WO2022010491A1 (fr) 2020-07-10 2020-07-10 Commutation de version d'application

Country Status (1)

Country Link
WO (1) WO2022010491A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004040399A2 (fr) * 2002-10-28 2004-05-13 Jgr Acquisition, Inc. Support ejb transparent et partition horizontale de donnees
WO2005024666A2 (fr) * 2003-08-21 2005-03-17 Microsoft Corporation Systemes et procedes d'extension et d'heritage pour des unites d'informations pouvant etre gerees par un systeme d'interface materiel/logiciel
US20080209390A1 (en) * 2007-02-27 2008-08-28 Microsoft Corporation Pluggable model elements
WO2009082821A1 (fr) * 2007-12-27 2009-07-09 Gtn Entertainment, Ltd Développement de site internet et utilisation de site internet pour des artistes
US20120036440A1 (en) * 2008-12-19 2012-02-09 Openpeak Inc. Supervisory portal systems and methods of operation of same
US20160371172A1 (en) * 2015-06-22 2016-12-22 Adobe Systems Incorporated Techniques for evaluating applications through use of an auxiliary application
US20170323089A1 (en) * 2016-05-06 2017-11-09 Enterpriseweb Llc Systems and methods for domain-driven design and execution of modular and dynamic services, applications and processes

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004040399A2 (fr) * 2002-10-28 2004-05-13 Jgr Acquisition, Inc. Support ejb transparent et partition horizontale de donnees
WO2005024666A2 (fr) * 2003-08-21 2005-03-17 Microsoft Corporation Systemes et procedes d'extension et d'heritage pour des unites d'informations pouvant etre gerees par un systeme d'interface materiel/logiciel
US20080209390A1 (en) * 2007-02-27 2008-08-28 Microsoft Corporation Pluggable model elements
WO2009082821A1 (fr) * 2007-12-27 2009-07-09 Gtn Entertainment, Ltd Développement de site internet et utilisation de site internet pour des artistes
US20120036440A1 (en) * 2008-12-19 2012-02-09 Openpeak Inc. Supervisory portal systems and methods of operation of same
US20160371172A1 (en) * 2015-06-22 2016-12-22 Adobe Systems Incorporated Techniques for evaluating applications through use of an auxiliary application
US20170323089A1 (en) * 2016-05-06 2017-11-09 Enterpriseweb Llc Systems and methods for domain-driven design and execution of modular and dynamic services, applications and processes

Similar Documents

Publication Publication Date Title
US11663208B2 (en) Computer data system current row position query language construct and array processing query language constructs
CN107622091B (zh) 一种数据库查询方法和装置
US9317706B2 (en) Multi-tenant system
CN102841841B (zh) 一种测试中的断言处理方法及系统
CN110727929A (zh) 基于aop的行级权限控制方法、装置及客户端
US20090210866A1 (en) Methods, systems, and computer program products for updating software on a data processing system based on transition rules between classes of compatible versions
US10997131B1 (en) Using a member attribute to perform a database operation on a computing device
US10740286B1 (en) Migration task validation before data migration
US8078914B2 (en) Open error-handling system
US20180307736A1 (en) Efficient Snapshot Generation of Data Tables
US20230418808A1 (en) Maintaining data separation for data consolidated from multiple data artifact instances
EP3107010B1 (fr) Pipeline d'intégration de données
US8131884B1 (en) Reusing system configuration information and metadata for related operations
KR102011354B1 (ko) 다수의 중첩하는 소스들로부터 대량의 시간적 데이터의 어그리게이트
WO2022010491A1 (fr) Commutation de version d'application
US20230222165A1 (en) Object storage-based indexing systems and method
US11023426B1 (en) Method and system for detection of open source web application version
US11169979B2 (en) Database-documentation propagation via temporal log backtracking
US11663211B2 (en) Data retrieval systems and methods
US11379432B2 (en) File management using a temporal database architecture
CN113868344A (zh) 面向电力应用的构建系统、方法、装置、服务器及存储介质
CN113760875A (zh) 一种数据处理方法、装置、电子设备和存储介质
US10762076B1 (en) Memory efficient database change management
CN113327167B (zh) 一种区块链数据处理方法
US11275725B2 (en) Transporting a database structure from a first version to a second version

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20944449

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20944449

Country of ref document: EP

Kind code of ref document: A1