A service script execution method, system, medium and terminal supporting multiple terminals

CN122884535APending Publication Date: 2026-10-09粤港澳大湾区(广东)国创中心
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611026338.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-10
Publication Date
2026-10-09

AI Technical Summary

Technical Problem

1)为C++终端编写的脚本因直接调用特定界面框架的API,无法在Web端或无图形界面终端的自动化环境中直接运行,导致脚本无法复用;

Benefits of technology

[0014]与现有技术相比,本发明的一种支持多终端的业务脚本执行方法的有益效果如下:通过编写与终端无关的通用业务脚本,并将界面交互逻辑抽离为终端自行注册的界面回调函数,使同一份通用业务脚本可在不同终端下复用;同时,各终端只需独立实现一次界面回调函数并完成注册,无需在每个业务功能中重复编写粘合代码,显著降低了多终端开发和维护成本。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122884535A_ABST
    Figure CN122884535A_ABST
Patent Text Reader

Abstract

The application discloses a kind of supporting multi-terminal service script execution method, system, medium and terminal, method includes: in response to terminal starting host software, terminal is based on the interface callback function of terminal registration interface framework itself, and is stored in the interface callback registry of host software;In response to host software executing general service script irrelevant to terminal, according to the target terminal of current running host software, the interface callback function of target terminal is inquired in interface callback registry;If the interface callback function of target terminal is inquired, then the target parameter is obtained based on the interface callback function of target terminal;If the interface callback function of target terminal is not inquired, then preset parameter is used as target parameter;Host software executes the business function corresponding to general service script based on target parameter.It can decouple service script and front-end interaction interface, so that the same script can seamlessly adapt different terminals and execute the same business function.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of software technology, and in particular to a method, system, medium, and terminal for executing business scripts that support multiple terminals. Background Technology

[0002] In existing multi-terminal hosting software, core functions such as geometric modeling and simulation analysis are usually implemented using underlying C++ libraries, while the user interface varies depending on the terminal. However, current technical solutions have the following significant drawbacks: 1) Scripts written for C++ terminals cannot be run directly on the web or in automation environments without graphical interfaces because they directly call the APIs of specific interface frameworks, resulting in the inability to reuse the scripts. 2) Each terminal needs to independently develop a set of glue code to convert interface input into underlying function calls. Different terminals have multiple code libraries when implementing the same function but with different implementations, which increases development and maintenance costs. Therefore, there is an urgent need for a method to decouple business scripts from the front-end interactive interface, so that the same script can be seamlessly adapted to different terminals and perform the same business functions. Summary of the Invention

[0003] In order to overcome the shortcomings of the prior art, the purpose of this invention is to provide a business script execution method, system, medium and terminal that supports multiple terminals, which can decouple the business script from the front-end interactive interface, so that the same script can be seamlessly adapted to different terminals and execute the same business function.

[0004] This invention is implemented according to the following scheme: A method for executing business scripts that supports multiple terminals is provided, including: In response to the terminal launching the host software, the terminal registers its own interface callback function based on its own interface framework and stores it in the interface callback registry of the host software. In response to the host software executing a terminal-independent general business script, the interface callback function of the target terminal is queried in the interface callback registry according to the target terminal currently running the host software; If the interface callback function of the target terminal is found, the target parameters are obtained based on the interface callback function of the target terminal. If the interface callback function of the target terminal is not found, the preset parameter will be used as the target parameter. The host software executes the business functions corresponding to the general business script based on the target parameters.

[0005] Optionally, the terminal registers its own interface callback functions based on its interface framework and stores them in the interface callback registry of the host software, including: The terminal defines an interface callback function based on its own interface framework. The interface callback function is used to generate the parameter input interface when it is called. The terminal calls the registration interface provided by the host software and stores the address of the interface callback function in the interface callback registry.

[0006] Optionally, the host software includes an interface callback scheduler embedded in the parameter acquisition interface; In response to the host software executing a terminal-independent general business script, the interface callback function of the target terminal is queried in the interface callback registry based on the target terminal currently running the host software, including: In response to the general business script calling the parameter acquisition interface, the interface callback scheduler queries the interface callback registry for the interface callback function of the target terminal.

[0007] Optionally, obtaining target parameters based on the interface callback function of the target terminal includes: Based on the interface callback function of the target terminal, a parameter input interface is generated; In response to the user's confirmation operation on the parameter input interface, the user input data in the parameter input interface is obtained, and the user input data is used as the target parameter.

[0008] Optionally, if no interface callback function for the target terminal is found, preset parameters are used as the target parameters, including: When the interface callback scheduler does not find the interface callback function of the target terminal in the interface callback registry, it uses the preset parameters pre-configured in the general business script as the target parameters.

[0009] Optionally, the host software executes the business function corresponding to the general business script based on the target parameters, including: The general business script calls the underlying core function engine of the host software and passes the target parameters to the underlying core function engine; The underlying core function engine executes the business function according to the target parameters.

[0010] Optionally, the general business scripts with the same business functions are the same on different terminals.

[0011] A business script execution system supporting multiple terminals is also provided, and the method for executing business scripts supporting multiple terminals is described above, including: The registration module responds to the terminal starting the host software by having the terminal register its own interface callback functions based on its own interface framework and store them in the interface callback registry of the host software. The UI callback module is used for: In response to the host software executing a terminal-independent general business script, the interface callback function of the target terminal is queried in the interface callback registry according to the target terminal currently running the host software; If the interface callback function of the target terminal is found, the target parameters are obtained based on the interface callback function of the target terminal. If the interface callback function of the target terminal is not found, the preset parameter will be used as the target parameter. The execution module, in which the host software executes the business functions corresponding to the general business script based on the target parameters.

[0012] A readable storage medium is also provided, which is terminal-readable storage medium, on which a computer program is stored, and when the computer program is executed, it implements a business script execution method that supports multiple terminals.

[0013] A terminal is also provided, including a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the processor loads and executes at least one instruction, at least one program, code set or instruction set to implement a business script execution method that supports multiple terminals.

[0014] Compared with the prior art, the beneficial effects of the business script execution method supporting multiple terminals of the present invention are as follows: by writing a general business script that is independent of the terminal and extracting the interface interaction logic into an interface callback function registered by the terminal itself, the same general business script can be reused on different terminals; at the same time, each terminal only needs to implement the interface callback function independently once and complete the registration, without having to repeatedly write glue code in each business function, which significantly reduces the development and maintenance costs of multiple terminals. Attached Figure Description

[0015] Figure 1 This is a flowchart of the method for performing the present invention. Detailed Implementation

[0016] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0017] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0018] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0019] See Figure 1 As shown, a business script execution method supporting multiple terminals according to the present invention includes: S1: In response to the terminal starting the host software, the terminal registers its own interface callback function based on its own interface framework and stores it in the host software's interface callback registry. This includes: the terminal defining the interface callback function based on its own interface framework, which is used to generate a parameter input interface when called; and the terminal calling the registration interface provided by the host software to store the address of the interface callback function in the interface callback registry.

[0020] In one embodiment of the present invention, the terminal implements the interface callback function based on an interface framework such as wxPython; the core module of the host software is exposed to the outside world as a unified script object NCTI. The registration interface provided by the script object NCTI is NCTI.SetPyInputDialogCallback. The terminal completes the registration by calling NCTI.SetPyInputDialogCallback(InputDialog), where InputDialog is the function name of the interface callback function.

[0021] In practical applications, the registration interface NCTI.SetPyInputDialogCallback does not care about how the interface is drawn; it is only responsible for recording the address of the interface callback function of the current terminal. Moreover, the registration process is independent of specific business functions. Different business functions, such as generating a cuboid or a cylinder, can reuse the same registered interface callback function. After registration, the host software has the ability to pop up the interface on the terminal. When executing any general business script with different business functions, there is no need to re-register, thus achieving reuse under different business functions.

[0022] When the terminal first starts the host software, the present invention registers the terminal's interface callback function based on its own interface framework. When the host software executes the business scripts subsequently, the host software generates an interface that conforms to the current terminal's native interaction specifications based on the interface callback function. This allows the business scripts to completely decouple from the terminal interface without containing any terminal-specific interface drawing or calling code.

[0023] This invention also stores the interface callback functions corresponding to each terminal in the interface callback registry of the host software. This allows the host software to directly obtain the corresponding interface callback function from the interface callback registry and complete the call when used on different terminals, based on the target terminal currently running. This avoids the need for the terminal to re-register the interface callback function every time the host software is started, and enables the interface callback capability to be registered once and reused as needed, thereby improving the running efficiency of the host software on multiple terminals.

[0024] S2: In response to the host software executing a terminal-independent general business script, query the interface callback function of the target terminal in the interface callback registry according to the target terminal currently running the host software; wherein, the general business script with the same business function is the same under different terminals.

[0025] In one embodiment of the present invention, the host software includes an interface callback scheduler embedded in the parameter acquisition interface; in response to the host software executing a terminal-independent general business script, the interface callback scheduler queries the interface callback function of the target terminal in the interface callback registry according to the target terminal currently running the host software, including: in response to the general business script calling the parameter acquisition interface, the interface callback scheduler queries the interface callback function of the target terminal in the interface callback registry.

[0026] In one embodiment of the present invention, the host software includes a document object module doc, which is a sub-object of the script object NCTI. The parameter acquisition interface is the doc.ReturnDialogData interface provided by the document object module doc. The interface callback scheduler is embedded in the parameter acquisition interface doc.ReturnDialogData and is not exposed to the developer separately. When the developer writes a terminal-independent general business script, the general business script does not contain any terminal-specific user interface drawing code or calling code, and does not need to be aware of whether the current terminal has an interface or how the interface is implemented.

[0027] When the general business script executes to the point of calling the parameter retrieval interface doc.ReturnDialogData, the interface callback scheduler embedded in this parameter retrieval interface is automatically started. Based on the target terminal of the currently running host software, it queries the interface callback registry for the interface callback function corresponding to the target terminal. This allows the interface to be generated on the target terminal even if the general business script does not contain user interface drawing code specific to the target terminal.

[0028] In practical applications, the interface callback scheduler does not require manual invocation or configuration by developers. Its scheduling logic is built into the parameter acquisition interface doc.ReturnDialogData, and its scheduling logic remains consistent across different terminals. This invention, by setting an interface callback scheduler embedded in the parameter acquisition interface within the host software, allows the interface callback scheduler to automatically take over the query logic when a general business script calls the parameter acquisition interface. The general business script does not need to be aware of the query process, the existence of the interface, or how the interface is implemented, further achieving complete decoupling between the business script and the terminal interface, while ensuring the consistency of the scheduling logic across all terminals.

[0029] This invention also embeds the interface callback scheduler into the parameter acquisition interface, without exposing it separately to developers. This allows developers to write general business scripts without having to pay attention to the existence of scheduling logic or write any code related to interface scheduling in the scripts, further reducing the development complexity of general business scripts.

[0030] In one embodiment of the present invention, when the general business script calls the parameter acquisition interface, an initial parameter list pre-configured in the general business script is also passed to the parameter acquisition interface. The initial parameter list is a component of the general business script and corresponds to the business function implemented by the general business script. It is used to represent the name, data type and default value of one or more parameters required by the host software to execute the business function.

[0031] S3: If the interface callback function of the target terminal is found, the target parameter is obtained based on the interface callback function of the target terminal, including: generating a parameter input interface based on the interface callback function of the target terminal; in response to the user's confirmation operation on the parameter input interface, obtaining the user input data in the parameter input interface, and using the user input data as the target parameter.

[0032] In one embodiment of the present invention, when the interface callback scheduler finds the interface callback function corresponding to the target terminal in the interface callback registry, it passes the initial parameter list of the general business script input parameter acquisition interface to the interface callback function. After the interface callback function is called and receives the initial parameter list passed by the parameter acquisition interface, it calls the control generation interface of the target terminal's own interface framework according to the parameter name and data type in the initial parameter list, and dynamically generates a parameter input interface containing the corresponding input controls. After the user inputs or modifies the parameters through the parameter input interface and performs a confirmation operation, the interface callback function responds to the confirmation operation performed by the user, collects the user input data in each input control in the parameter input interface, and assembles the user input data as the target parameter and returns it to the general business script.

[0033] For example, in a general business script for creating a cuboid, the initial parameter list includes the cuboid's name, length, width, and height. The interface callback function dynamically generates a parameter input interface with four input boxes based on these four parameters. After the user modifies the values ​​in each input box and clicks "confirm," the interface callback function retrieves the modified name, length, width, and height values ​​as the target parameters.

[0034] In the general business script for creating a cylinder, the initial parameter list includes three parameters: cylinder name, radius, and height. The interface callback function dynamically generates a parameter input interface with two input boxes based on these three parameters. After the user modifies the values ​​in each input box and clicks "confirm," the interface callback function retrieves the modified name, radius, and height values ​​as the target parameters.

[0035] In practical applications, the interface callback function does not concern itself with the meaning of specific business functions. It only dynamically generates the interface and collects user input based on the structure and data type of the passed parameter list. Therefore, for the same terminal, regardless of whether the business function corresponding to the general business script is to create a cuboid or a cylinder, the same interface callback function can be reused without writing separate interface code for different business functions. Furthermore, this process is automatically triggered by the host software at runtime based on the query results of the interface callback function. The general business script does not need to be aware of the existence and calling process of the interface callback function, nor does it need to care about how the interface is drawn or how user input is collected. It can obtain the target parameters simply by obtaining the initial parameter list passed by the parameter acquisition interface.

[0036] S4: If the interface callback function of the target terminal is not found, the preset parameters will be used as the target parameters, including: when the interface callback scheduler does not find the interface callback function of the target terminal in the interface callback registry, the preset parameters pre-configured in the general business script will be used as the target parameters.

[0037] In practical applications, terminal environments without graphical interfaces, such as continuous integration servers, automated testing frameworks, or cloud batch processing nodes, do not register any interface callback functions with the host software. Therefore, there are no interface callback functions corresponding to the target terminal in the interface callback registry.

[0038] In one embodiment of the present invention, when the interface callback scheduler does not find an interface callback function corresponding to the target terminal in the interface callback registry, it means that the current running host software is a terminal environment such as an automated testing environment, command line environment, or batch processing environment without a graphical interface that does not have the ability to pop up a native interface. At this time, the host software does not perform any interface interaction operation, but directly obtains the initial parameter list passed when the general business script calls the parameter acquisition interface, and uses the default value of each parameter in the initial parameter list as the preset parameter.

[0039] This invention uses preset parameters as target parameters, eliminating the need to write additional silent execution logic for automated testing or batch processing scenarios when writing general business scripts. The same general business script can simultaneously support interactive running and silent automated execution, effectively reducing the cost of writing and maintaining automated test scripts, improving the adaptability and reusability of general business scripts in different terminal environments, and solving the problem of complex, fragile, and inefficient test scripts caused by simulating user clicks and inputs when automating functions that rely on graphical interfaces in existing technologies.

[0040] Throughout the process, the general business script does not need to distinguish whether the current terminal has a screen or not, nor does it need to write any conditional judgment code. The same general business script will pop up an interactive window for user input on a screen terminal, and will be executed silently using the pre-configured parameters in the script on a screenless terminal, thus realizing the adaptive operation of the same script in both screen-based and screenless environments.

[0041] S5: The host software executes the business functions corresponding to the general business script based on the target parameters, including: the general business script calls the underlying core function engine of the host software and passes the target parameters to the underlying core function engine; the underlying core function engine executes the business functions according to the target parameters.

[0042] In one embodiment of the present invention, the underlying core function engine of the host software is the original function execution module of the host software, which is used to perform core business functions such as geometric modeling, simulation analysis or design calculation, and the underlying core function engine is completely independent of the interface; after the general business script obtains the target parameters, the general business script calls the function interface provided by the underlying core function engine according to its business function, and passes the target parameters to the underlying core function engine; after receiving the target parameters, the underlying core function engine executes the corresponding business function according to the target parameters and returns the execution result to the general business script.

[0043] For example, in the general business script for creating a cuboid, the script calls the core_engine.create_box function interface of the underlying core function engine, passing the target parameters including the cuboid's name, length, width, and height to the interface. The underlying core function engine then performs the cuboid creation operation based on the target parameters. Similarly, in the general business script for creating a cylinder, the script calls the core_engine.create_cylinder function interface of the underlying core function engine, passing the target parameters including the cylinder's name, radius, and height to the interface. The underlying core function engine then performs the cylinder creation operation based on the target parameters.

[0044] In practical applications, the calling code of the general business script to call the underlying core function engine is exactly the same on different terminals. Regardless of whether the target parameter comes from the user interface input or the script's preset parameter, the entire execution path of the general business script to call the underlying core function engine, pass the target parameter, and the underlying core function engine to execute the business function according to the target parameter is completely consistent on all terminals.

[0045] This invention calls the underlying core function engine of the host software through a general business script. The underlying core function engine executes business functions according to target parameters, completing business functions based on the same set of execution logic. The execution path is exactly the same on all terminals, fundamentally eliminating the risk of inconsistent functional behavior caused by differences in terminal interface implementation. At the same time, since the underlying core function engine is completely decoupled from the interface, the underlying core function engine does not need to care about the existence of the interface, how the interface is implemented, or where the parameters come from. It only needs to receive the target parameters and execute the corresponding business functions. This allows the development, testing, and maintenance of the underlying core function engine to be carried out independently of the terminal interface development, further reducing the overall complexity and maintenance cost of the host software.

[0046] The present invention provides a business script execution system supporting multiple terminals, which applies the aforementioned business script execution method supporting multiple terminals, including: The registration module responds to the terminal starting the host software by having the terminal register its own interface callback functions based on its own interface framework and store them in the host software's interface callback registry. The UI callback module is used for: In response to the host software executing a general business script independent of the terminal, the interface callback function of the target terminal is queried in the interface callback registry according to the target terminal currently running the host software. If the interface callback function of the target terminal is found, the target parameters are obtained based on the interface callback function of the target terminal. If no interface callback function for the target terminal is found, the preset parameters will be used as the target parameters. The execution module is where the host software executes the business functions corresponding to the general business script based on the target parameters.

[0047] This invention discloses a readable storage medium, which is terminal-readable, and stores a computer program thereon. When the computer program is executed, it implements the above-mentioned business script execution method that supports multiple terminals.

[0048] Optionally, the readable storage medium may include: read-only memory (ROM), random access memory (RAM), solid-state drive (SSD), or optical disk, etc. The random access memory may include resistive random access memory (ReRAM) and dynamic random access memory (DRAM).

[0049] The terminal of the present invention includes a processor and a memory. The memory stores at least one instruction, at least one program, code set or instruction set. The at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the above-mentioned business script execution method supporting multiple terminals.

[0050] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0051] Memory can be used to store computer programs or modules. The processor, by running or executing the computer programs or modules stored in memory and accessing data stored in memory, implements various functions supporting multi-terminal business script execution methods. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on terminal usage, etc. Furthermore, memory can include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, SmartMediaCard (SMC), Secure Digital (SD) cards, FlashCards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0052] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for executing business scripts supporting multiple terminals, characterized in that, include: In response to the terminal launching the host software, the terminal registers its own interface callback function based on its own interface framework and stores it in the interface callback registry of the host software. In response to the host software executing a terminal-independent general business script, the interface callback function of the target terminal is queried in the interface callback registry according to the target terminal currently running the host software; If the interface callback function of the target terminal is found, the target parameters are obtained based on the interface callback function of the target terminal. If the interface callback function of the target terminal is not found, the preset parameter will be used as the target parameter. The host software executes the business functions corresponding to the general business script based on the target parameters.

2. The method for executing business scripts supporting multiple terminals according to claim 1, characterized in that, The terminal registers its own interface callback functions based on its own interface framework and stores them in the interface callback registry of the host software, including: The terminal defines an interface callback function based on its own interface framework. The interface callback function is used to generate the parameter input interface when it is called. The terminal calls the registration interface provided by the host software and stores the address of the interface callback function in the interface callback registry.

3. The method for executing business scripts supporting multiple terminals according to claim 1, characterized in that, The host software includes an interface callback scheduler embedded in the parameter acquisition interface; In response to the host software executing a terminal-independent general business script, the interface callback function of the target terminal is queried in the interface callback registry based on the target terminal currently running the host software, including: In response to the general business script calling the parameter acquisition interface, the interface callback scheduler queries the interface callback registry for the interface callback function of the target terminal.

4. The method for executing business scripts supporting multiple terminals according to claim 1, characterized in that, Obtaining target parameters based on the interface callback function of the target terminal includes: Based on the interface callback function of the target terminal, a parameter input interface is generated; In response to the user's confirmation operation on the parameter input interface, the user input data in the parameter input interface is obtained, and the user input data is used as the target parameter.

5. A method for executing business scripts supporting multiple terminals according to claim 3, characterized in that, If the interface callback function of the target terminal is not found, then the preset parameters are used as the target parameters, including: When the interface callback scheduler does not find the interface callback function of the target terminal in the interface callback registry, it uses the preset parameters pre-configured in the general business script as the target parameters.

6. The method for executing business scripts supporting multiple terminals according to claim 1, characterized in that, The host software executes the business functions corresponding to the general business script based on the target parameters, including: The general business script calls the underlying core function engine of the host software and passes the target parameters to the underlying core function engine; The underlying core function engine executes the business function according to the target parameters.

7. The method for executing business scripts supporting multiple terminals according to claim 1, characterized in that, The general business scripts with the same business functions are the same on different terminals.

8. A business script execution system supporting multiple terminals, employing the business script execution method supporting multiple terminals as described in any one of claims 1-7, characterized in that, include: The registration module responds to the terminal starting the host software by having the terminal register its own interface callback functions based on its own interface framework and store them in the interface callback registry of the host software. The UI callback module is used for: In response to the host software executing a terminal-independent general business script, the interface callback function of the target terminal is queried in the interface callback registry according to the target terminal currently running the host software; If the interface callback function of the target terminal is found, the target parameters are obtained based on the interface callback function of the target terminal. If the interface callback function of the target terminal is not found, the preset parameter will be used as the target parameter. The execution module, in which the host software executes the business functions corresponding to the general business script based on the target parameters.

9. A readable storage medium, characterized in that, It is a terminal-readable storage medium on which a computer program is stored. When the computer program is executed, it implements a business script execution method supporting multiple terminals as described in any one of claims 1-7.

10. A terminal, characterized in that, The terminal includes a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, at least one program, code set or instruction set being loaded and executed by the processor to implement a business script execution method supporting multiple terminals as claimed in any one of claims 1-7.