Application online and rollback method and system

Abstract

The invention discloses an application online and rollback method and system. The method comprises the steps that in response to a version issuing instruction, a DSL file of a target application is automatically exported, the DSL file is synchronized to an online environment, version control is conducted on the DSL file, a version identifier is generated, and historical change information is recorded; in a version issuing process, automatically detecting and analyzing an application dependency item of the DSL file, and ensuring the consistency of a dependency version and a target environment; and in response to a rollback instruction, retrieving a target version from the historical change information according to the version identifier, automatically rolling back to the target version, and verifying environment consistency. The technical problem that in the prior art, version management and dependency processing are complex, and data inconsistency is easily caused is solved.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular, to a method and system for online deployment and rollback of an application. Background Art

[0002] In modern distributed systems and microservice architectures, the version release and rollback management of application systems has become a key technical link to ensure business continuity. Traditional application release management solutions generally adopt a manual intervention version control method, which is specifically manifested in: (1) In terms of the version management of DSL (Domain Specific Language) configuration files, operation and maintenance personnel need to manually export configuration files in different environments and perform difference analysis through file comparison tools. This process has the risk of human operation errors and it is difficult to ensure the consistency of multi-environment configurations; (2) In the dimension of dependency management, existing technologies mostly adopt a static dependency declaration mechanism and lack the dynamic parsing ability of the runtime dependency chain. When the version of the dependency library conflicts with the environment requirements, it is easy to cause the "dependency hell" phenomenon; (3) Version rollback operations usually rely on backup and recovery mechanisms, and it is impossible to achieve accurate traceability based on semantic version identifiers. Moreover, the environment verification process after rollback lacks automated detection means, resulting in insufficient timeliness and reliability of system recovery.

[0003] The existing technical solutions mainly have the following technical defects: First, the manual operation DSL file synchronization mechanism is prone to configuration drift. Especially in the multi-environment deployment scenario, the manual modification of configuration items is likely to cause the data state mismatch between the production environment and the pre-release environment; Second, the dependency version management lacks an environment adaptability verification module. When there is a forward incompatibility in the version of the dependent service, it is easy to cause the application to fail to start or runtime exceptions; Third, the traditional version rollback method does not establish the association relationship between the version snapshot and the dependency graph. The rollback operation may damage the existing dependency ecosystem and cause secondary system failures. These technical defects together lead to technical bottlenecks such as reduced release success rate, extended fault recovery cycle, and increased operation and maintenance costs in the existing system during the version iteration process.

[0004] In response to the above problems, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of the present invention provide a method and system for online deployment and rollback of an application to at least solve the technical problem that version management and dependency processing in the prior art are complex and easily lead to data inconsistency.

[0006] According to one aspect of the embodiments of the present invention, a method for the online release and rollback of an application is provided, including: in response to a release instruction, automatically exporting a Domain Specific Language (DSL) file of the target application, synchronizing the DSL file to the online environment, and performing version control on the DSL file to generate a version identifier and record historical change information; during the release process, automatically detecting and parsing the application dependencies of the DSL file to ensure the consistency of the dependency versions with the target environment; in response to a rollback instruction, retrieving the target version from the historical change information according to the version identifier, automatically rolling back to the target version and verifying the environmental consistency.

[0007] According to another aspect of the embodiments of the present invention, a system for the online release and rollback of an application is further provided, including: a release module configured to, in response to a release instruction, automatically export a Domain Specific Language (DSL) file of the target application, synchronize the DSL file to the online environment, and perform version control on the DSL file to generate a version identifier and record historical change information; a dependency check module configured to automatically detect and parse the application dependencies of the DSL file during the release process to ensure the consistency of the dependency versions with the target environment; a rollback module configured to, in response to a rollback instruction, retrieve the target version from the historical change information according to the version identifier, automatically roll back to the target version and verify the environmental consistency.

[0008] In the embodiments of the present invention, in response to a release instruction, a Domain Specific Language (DSL) file of the target application is automatically exported, the DSL file is synchronized to the online environment, and version control is performed on the DSL file to generate a version identifier and record historical change information; during the release process, the application dependencies of the DSL file are automatically detected and parsed to ensure the consistency of the dependency versions with the target environment; in response to a rollback instruction, the target version is retrieved from the historical change information according to the version identifier, and automatically rolled back to the target version and the environmental consistency is verified. Through the above solution, the technical problems in the prior art that version management and dependency processing are complex and easily lead to data inconsistency are solved. Description of the Drawings

[0009] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation to the present invention. In the drawings:

[0010] Figure 1 is a flowchart of a method for the online release and rollback of an application according to an embodiment of the present invention;

[0011] Figure 2 is an online release flowchart of an optimized method for the online release and rollback of a modify application according to an embodiment of the present invention;

[0012] Figure 3 It is a rollback flowchart of a method for optimizing the online and rollback processes of a dify application according to an embodiment of the present invention;

[0013] Figure 4 It is a flowchart of another method for online and rollback of an application according to an embodiment of the present invention;

[0014] Figure 5 It is an architecture diagram of an online and rollback system of an application according to an embodiment of the present invention;

[0015] Figure 6 It shows a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. Detailed implementation manners

[0016] In order to enable those skilled in the art of this technology to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0017] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present invention described herein can be implemented in an order different from those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device including a series of steps or units does not necessarily need to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0018] According to an embodiment of the present invention, a method embodiment of a method for online and rollback of an application is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0019] Figure 1 It is a flowchart of a method for online and rollback of an application according to an embodiment of the present invention, as Figure 1 shown, the method includes the following steps:

[0020] Step S102, in response to the version release instruction, automatically export the domain-specific language DSL file of the target application, synchronize the DSL file to the online environment, perform version control on the DSL file, generate a version identifier and record historical change information.

[0021] First, perform online synchronization. For example, based on the preset configuration file, the target application configuration of the local development environment is converted into the standardized DSL file; the DSL file is uploaded to the version repository of the online environment through the API interface, and the automated deployment service is triggered to execute the environment synchronization. This solution automatically converts the local environment configuration into a standardized DSL file based on a preset configuration template, eliminating syntax errors and format deviations caused by manual writing; through the automated docking of the API interface and the version repository, an end-to-end deployment pipeline is built, which not only avoids the omission or tampering of configuration items that may be caused by manual transmission, but also ensures file integrity through the hash verification mechanism of the version repository.

[0022] Next, record the historical change information. For example, generate a unique hash value as a version identifier for each release of the DSL file, and store the hash value in association with the content, dependency list, and environment configuration information of the DSL file; build a historical change chain based on the timestamp and the version identifier as the historical change information, wherein the historical change chain supports retrieval by version identifier or time range. This solution uses a version identification system built based on a unique hash value to associate and store the DSL file content, dependency list, and environment configuration information, ensuring that each release record is tamper-proof; through the design of a historical change chain that links timestamps and version identifiers, it is possible to accurately locate the target version in minutes, greatly improving the efficiency of version retrieval in fault scenarios.

[0023] Step S104, during the release process, automatically detect and parse the application dependencies of the DSL file to ensure the consistency of the dependency version with the target environment.

[0024] For example, the dependency library name and version constraints are extracted from the DSL file and compared with the dependency library version of the online environment; if there is a version conflict, the dependency management tool is automatically called to adjust the dependency version to a compatible state to ensure the consistency of the dependency version with the target environment. This solution is based on the collaborative verification of static parsing of DSL files and dynamic comparison of online environments, and uses a semantic version constraint matching algorithm to detect dependency conflicts in real time, which shortens the time spent on version compatibility verification compared to traditional manual troubleshooting; in addition, by automatically calling the dependency management tool to perform version corrections, a closed-loop dependency adaptation system is built, which greatly reduces the application startup failure rate caused by version conflicts.

[0025] Step S106, in response to the rollback instruction, retrieve the target version from the historical change information according to the version identifier, automatically roll back to the target version, and verify the environmental consistency.

[0026] First, perform the rollback. According to the version identifier in the rollback instruction, obtain the corresponding historical DSL file from the historical change information; restore the application configuration based on the historical DSL file, and re-parse the dependencies to match the environmental state of the rollback target. Next, verify the environmental consistency. After the rollback is completed, execute the predefined consistency check script to verify the integrity of the application functions, dependency versions, and configuration parameters; if the check fails, automatically trigger an alarm and generate repair suggestions.

[0027] This solution realizes the atomic reduction of the historical DSL file based on the version identifier, combines the dependency graph reconstruction technology to dynamically adapt to the target environment dependency version, improves the accuracy of the configuration reduction in the rollback operation, and avoids the secondary failures caused by dependency drift in traditional rollbacks; in the verification stage, perform multi-dimensional consistency verification through the preset check script, and automatically generate the repair path using the anomaly detection model, greatly reducing the time-consuming of the environmental state verification.

[0028] Dify, as an open-source large language model application development platform, allows users to quickly build production-level generative AI applications. In the existing technology, the online and rollback processes of Dify applications mainly rely on manual operations, including exporting the DSL file, importing the DSL file in the online environment, and manually rolling back to the previous version when needed. These manual operations are not only inefficient but also error-prone, especially in terms of version management and dependency handling. Therefore, the existing Dify application online and rollback processes have the following problems: many manual operations and high error rates. Version management and dependency handling are complex and prone to data inconsistency. The rollback process is cumbersome and lacks automated support.

[0029] To solve the above problems, the present invention provides an optimization method for the Dify application online and rollback process. This embodiment adopts an automated release process, reducing manual intervention; in addition, through version control and historical tracking, the traceability of each release and rollback is ensured; finally, through dependency and consistency management, the consistency of the application and its dependencies is ensured.

[0030] The online process is as Figure 2 shown and includes the following steps:

[0031] Step S202, the operation and maintenance general approval submission, create a new Dify application (need to provide appId, application name, application description).

[0032] Step S204, the operation and maintenance approval and create the Dify application.

[0033] Step S206: When going live, test and select the application to go live on the crop platform.

[0034] Step S208: Call the architecture group to query the application knowledge base list interface to select which knowledge bases need to be published.

[0035] Step S210: Click the release button

[0036] Step S212: Call the release interface provided by the architecture group (type: "knowledge base, application", id, version)

[0037] Step S214: Execute the release process.

[0038] Export the data that needs to be released offline, back up the online data, and update the offline data to the online.

[0039] The rollback process is as Figure 3 shown and includes the following steps:

[0040] Step S302: Test and select the version of the application or knowledge base to be rolled back on the CRP platform.

[0041] Step S304: Click the rollback button.

[0042] Step S306: Call the rollback interface provided by the architecture group (type: "knowledge base, application", id, version).

[0043] Step S308: Execute the release process.

[0044] Query the data backed up for the version to be rolled back according to the version and update the online data.

[0045] The present invention adopts the following solutions: the automated release and rollback process of the dify-sync project; the version control and historical tracking mechanism; the dependency and consistency management strategy, which improves the efficiency and accuracy of the go-live and rollback processes, enhances the version management and dependency handling capabilities, simplifies the rollback process, and improves the stability and reliability of the system.

[0046] In other embodiments, cloud-based services can also be used. For example, utilize the automated deployment and rollback functions of cloud service providers.

[0047] The embodiment of the present application also provides a flowchart of another application go-live and rollback method. This method realizes the versioned deployment and precise rollback of DSL files through an automated pipeline, as Figure 4 shown. This method includes the following steps:

[0048] Step S402: Perform version control.

[0049] By building an end-to-end automated deployment pipeline, seamless connection from the local development environment to the online environment is achieved. First, the deployment system performs a standardized conversion on the application configuration in the local development environment based on a preset configuration template (such as JSON Schema or YAML structure definition) to generate a DSL file that conforms to the syntax specification. The definition rules of key parameters such as application topology structure, service dependency relationships, and resource quota constraints are preset in the configuration template, and the actual configuration values are dynamically filled through a template engine (such as Jinja2 or a custom parser) to ensure that the generated DSL file completely eliminates format errors that may be introduced by manual intervention.

[0050] In the file synchronization phase, interact with the online version repository (such as GitLab or Harbor) through RESTful API calls, upload the DSL file to a predefined version branch, and trigger a Webhook to notify the automated deployment service (such as Jenkins or Argo CD) to start the environment synchronization task. To ensure transmission security, the API interface adopts a two-way certificate authentication and request signature mechanism. During the file upload process, the built-in hash verification module in the version repository calculates the SHA-256 digest value of the file content in real time and compares it with the hash value submitted by the client. If they are inconsistent, the synchronization process is terminated and an alarm log is generated.

[0051] In terms of version control, the system generates a unique version identifier for each release. This identifier consists of three parts: a timestamp (accurate to milliseconds), a submitter identification code (a unique ID generated based on the LDAP system), and a file content hash value (generated using the BLAKE3 algorithm). The version identifier is stored in association with the DSL file content, the dependency list (including third-party library names, version numbers, and license information), and the environment configuration snapshot (such as the Kubernetes cluster status, database connection pool parameters). The storage layer adopts a multi-level index structure (including LSM tree and inverted index), supporting efficient retrieval by version identifier, time range, or dependency attributes. The historical change chain is implemented through a directed acyclic graph (DAG) data structure. Each version node records the parent version pointer and the differential increment, enabling quick positioning of the minimum change set during version rollback.

[0052] Traditional version identifiers usually rely only on timestamps or incrementing serial numbers, which have problems such as easy conflicts or missing information. This solution innovatively introduces the BLAKE3 hash algorithm to generate content fingerprints and constructs a composite version identifier in combination with the environment configuration snapshot to ensure version uniqueness and integrity. At the same time, the storage efficiency of the historical change chain is optimized through the DAG structure, reducing the time complexity of version retrieval.

[0053] Step S404, detect application dependencies to ensure the consistency of the dependency versions with the target environment.

[0054] In this embodiment, precise adaptation of dependent versions is achieved through a combination of static analysis and dynamic verification. First, the system extracts dependency declarations from DSL files (such as requirements.txt for Python or package.json for Node.js), and uses an Abstract Syntax Tree (AST) parser to identify the names of dependent libraries, version constraint conditions (such as semantic version ranges "^2.1.3"), and optional dependency markers. Subsequently, the dependency resolution engine calls the registry in the online environment (such as Nexus or NPM Registry) to obtain the list of currently available versions, and constructs a dependency graph based on an improved Constraint Satisfaction Problem (CSP) algorithm.

[0055] The improved CSP algorithm in this embodiment introduces a Conflict-Driven Clause Learning (CDCL) mechanism based on the traditional backtracking method: when a version conflict is detected (such as library A requiring library B ≥ 1.2.0, while library C requires library B ≤ 1.1.5), the algorithm will record the conflict path and generate a minimal unsatisfiable core, and then call a dependency management tool (such as pip or yarn) to perform intelligent downgrading or upgrading operations. For example, if there is no compatible version of library B, the system will automatically retrieve an alternative library with the same API interface in the public repository (such as through similarity matching of Swagger documents), and generate migration suggestions to be submitted to the approval queue.

[0056] After completing the dependency resolution, the system generates a dependency lock file (such as Pipfile.lock for Pipenv), which precisely specifies the version numbers of each dependent library and the dependency tree structure, and binds it to the DSL file for storage. During the deployment process, the system pre-executes the dependency installation script through a sandbox environment (such as a Docker container). If an installation failure or a test case fails is detected, the rollback process is automatically triggered and the version is marked as "high-risk status".

[0057] The prior art usually only performs simple version number comparison and cannot solve deep dependency conflicts. This solution significantly improves the efficiency of solving complex dependency conflicts by introducing a CDCL-enhanced CSP algorithm; at the same time, it breaks through the limitations of traditional dependency management by implementing intelligent replacement of dependent libraries through API similarity matching.

[0058] Step S406, perform rollback and verification.

[0059] The rollback process is divided into three stages: version retrieval, configuration restoration, and consistency verification. When a rollback instruction is received, the system first parses the version identifier in the instruction and extracts the corresponding DSL file, dependency lock file, and environment configuration snapshot from the historical change chain. To address the possible issue of the dependent library version being taken off the shelves, the system has a built-in private image repository caching mechanism: during each release, the binary files of the dependent libraries and all their historical versions are automatically archived to the private repository to ensure that the dependent environment can be fully reconstructed during rollback.

[0060] In the configuration restoration stage, the system regenerates the application deployment descriptor (such as the Deployment YAML for Kubernetes) based on the historical DSL file, and generates an incremental update script by comparing the resource configuration differences between the current online environment and the target version. For example, if the rollback involves changes to the database table structure, the system will automatically generate rollforward and rollback scripts to ensure that the data schema is strictly compatible with the application version.

[0061] The environment consistency verification adopts a multi-dimensional inspection strategy: at the functional level, a predefined API endpoint test suite (based on the Postman or Pytest framework) is executed to verify the correctness of the core business logic; at the dependency level, by comparing the hash values of the currently installed dependent libraries with the records in the lock file, it is ensured that the binary files have not been tampered with; at the configuration level, the status check interface of the infrastructure (such as kubectl describe for Kubernetes) is called to verify the consistency of parameters such as CPU quotas and storage volume mount points with the DSL file definition. If any inspection item fails, the system will trigger an alarm and input the exception information into the root cause analysis model (built based on decision trees and Bayesian networks) to generate repair suggestions (such as adjusting resource quotas or restarting the faulty service).

[0062] Traditional rollback mechanisms often fail due to unavailable dependent libraries or incompatible data schemas. This solution ensures the complete reproducibility of the rollback environment through private image repository caching and dynamic generation of data migration scripts; at the same time, combined with multi-dimensional consistency checks and intelligent repair suggestions, it realizes the self-healing ability during the rollback process.

[0063] This application also provides a system for the online deployment and rollback of an application, such as Figure 5As shown in the figure, it includes: a release module 12, which is configured to automatically export the domain-specific language (DSL) file of the target application in response to a release instruction, synchronize the DSL file to the online environment, and perform version control on the DSL file to generate a version identifier and record historical change information; a dependency check module 14, which is configured to automatically detect and resolve the application dependencies of the DSL file during the release process to ensure the consistency of the dependency versions with the target environment; and a rollback module 16, which is configured to retrieve the target version from the historical change information according to the version identifier in response to a rollback instruction, automatically roll back to the target version, and verify the environmental consistency.

[0064] It should be noted that: for the online and rollback system of the application provided in the above embodiment, only the division of the above functional modules is used for illustration. In actual applications, the above functions can be assigned to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the online and rollback system of the application provided in the above embodiment and the embodiment of the online and rollback system of the application belong to the same concept. For the specific implementation process, please refer to the method embodiment, which will not be elaborated here.

[0065] Figure 6 The figure shows a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. It should be noted that Figure 6 The electronic device shown is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present disclosure.

[0066] As Figure 6 shown in the figure, the electronic device includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage section 1008 into the random access memory (RAM) 1003. In the RAM 1003, various programs and data required for system operation are also stored. The CPU 1001, ROM 1002, and RAM 1003 are connected to each other through a bus 1004. The input / output (I / O) interface 1005 is also connected to the bus 1004.

[0067] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, etc.; an output section 1007 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. as well as a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, a modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as required. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is mounted on the drive 1010 as required so that a computer program read from it is installed into the storage section 1008 as required.

[0068] The above are only the preferred embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and modifications can be made, and these improvements and modifications should also be regarded as the protection scope of the present application.

Claims

1. A method for the online launch and rollback of an application, characterized in that, Including: In response to a release instruction, automatically export the domain-specific language (DSL) file of the target application, synchronize the DSL file to the online environment, and perform version control on the DSL file to generate a version identifier and record historical change information; During the release process, automatically detect and resolve the application dependencies of the DSL file to ensure the consistency of the dependency versions with the target environment; In response to a rollback instruction, retrieve the target version from the historical change information based on the version identifier, and automatically roll back to the target version and verify the environment consistency.

2. The method according to claim 1, wherein Automatically export the domain-specific language (DSL) file of the target application and synchronize the DSL file to the online environment, including: Based on a preset configuration file, convert the configuration of the target application in the local development environment into the standardized DSL file; Upload the DSL file to the version repository in the online environment through the API interface and trigger the automated deployment service to perform environment synchronization.

3. The method according to claim 2, wherein Perform version control on the DSL file to generate a version identifier and record historical change information, including: Generate a unique hash value for each release of the DSL file as the version identifier, and store the hash value in an associated manner with the content of the DSL file, the dependency list, and the environment configuration information; Construct a historical change chain based on the timestamp and the version identifier as the historical change information, where the historical change chain supports retrieval by version identifier or time range.

4. The method according to claim 1, wherein Automatically detect and resolve the application dependencies of the DSL file during the release process to ensure the consistency of the dependency versions with the target environment, including: Extract the dependency library names and version constraint conditions from the DSL file and compare them with the dependency library versions in the online environment; If there is a version conflict, automatically call the dependency management tool to adjust the dependency version to a compatible state to ensure the consistency of the dependency versions with the target environment.

5. The method according to claim 1, wherein Retrieve the target version from the historical change information based on the version identifier and automatically roll back to the target version, including: Based on the version identifier in the rollback instruction, obtain the corresponding historical DSL file from the historical change information; Restore the application configuration based on the historical DSL file and re-parse the dependencies to match the environment state of the rollback target.

6. The method according to claim 1, wherein Verify the environment consistency, including: After the rollback is completed, execute a predefined consistency check script to verify the integrity of the application functions, dependency versions, and configuration parameters; If the check fails, automatically trigger an alarm and generate repair suggestions.

7. An online and rollback system for an application, characterized in that Including: A release module, configured to, in response to a release instruction, automatically export the domain-specific language (DSL) file of the target application, synchronize the DSL file to the online environment, and perform version control on the DSL file to generate a version identifier and record historical change information; A dependency check module, configured to automatically detect and resolve the application dependencies of the DSL file during the release process to ensure the consistency of the dependency versions with the target environment; A rollback module, configured to, in response to a rollback instruction, retrieve the target version from the historical change information based on the version identifier, and automatically roll back to the target version and verify the environment consistency.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein when the program runs, it controls the device where the computer-readable storage medium is located to execute the method according to any one of claims 1 to 6.

9. A computer device, characterized in that, Comprising: a memory and a processor, the memory stores a computer program; the processor is configured to execute the computer program stored in the memory, and when the computer program runs, it causes the processor to execute the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 6.

Images