CN112486579A

CN112486579A - Self-service terminal device drive calling standardization method and related device

Info

Publication number: CN112486579A
Application number: CN202011315247.4A
Authority: CN
Inventors: 刘泽洋; 戴兴邦; 李川川; 刘晓颖
Original assignee: China Life Insurance Co ltd
Current assignee: China Life Insurance Co ltd
Priority date: 2020-11-20
Filing date: 2020-11-20
Publication date: 2021-03-12

Abstract

One or more embodiments of this specification provide a self-service terminal device driver call standardization method and related devices. First, encapsulate different drivers into different standard libraries with standard interfaces and the same driver method names and parameter names that implement the same function. Then, when the device is inserted into the self-service terminal, the self-service terminal will identify the MAC address and provider of the device, and generate the reference path of the standard library file according to the query in the configuration library, and call the corresponding standard library according to the reference path of the standard library file for deployment. To achieve the purpose of starting the business system and serving users. This self-service terminal device driver calls the standardized method and related equipment, which can realize that when a new device is added, only a set of standard libraries needs to be added, and there is no need to transform the business system, so that the business system can be loaded with different equipment manufacturers in a non-invasive way. standard library.

Description

Self-service terminal device drive calling standardization method and related device

Technical Field

One or more embodiments of the present description relate to the field of self-service terminal driver invocation, and in particular, to device driver invocation standardization.

Background

The application field from the assistant terminal has become more and more extensive in recent years, and the characteristics matched with modern life are popular due to convenience and rapidness; the self-service terminal can effectively reduce the operation cost, has the 24-hour working characteristic, breaks the limitation of space and time, and is popular in various scene fields; the self-service terminal can effectively liberate a high-frequency low-difficulty labor scene, liberate labor force and concentrate resources to serve high-quality customers; the self-service terminal can also perform personalized customization for the customer to a certain extent according to the customer needs, so as to meet specific requirements. Because self-service terminal has above advantage, the demand in each trade is more and more, has wide development prospect in the future.

For the use of various types of kiosks, the B/S (browser/server) system architecture is mostly chosen to maintain consistency in the user experience. Under the B/S architecture, the technical key is to call the driver from the browser. At present, the system is generally designed and developed by aiming at the drive of different models.

Different self-service terminal equipment providers all have their own driver designs. However, the driver designs of different equipment manufacturers cannot run across the terminal platform, so that when the same service provider adopts different self-service terminal equipment, the same service provider needs to develop the equipment for many times, run in a multi-set system mode, and increase the maintenance cost. And when the omission is modified, experience inconsistency and even failure of partial machine type business transaction can be caused.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure are directed to a method for standardizing device driver calls of self-service terminals and related devices, so as to solve the problem that different self-service terminals need to be developed for multiple times.

In view of the above, one or more embodiments of the present specification provide a method for standardizing driver calls of a self-service terminal device, including:

respectively packaging the respective drives of the self-service terminal equipment of different models into drive standard libraries with the same name;

when a service system is initialized, for a target self-service terminal device in the self-service terminal devices with different models configured in the background, a preset configuration library is inquired based on the model of the target self-service terminal device and a Media Access Control (MAC) address, a reference path of the driving standard library of the target self-service terminal device is generated, and the driving standard library of the target self-service terminal device is deployed under the reference path for reference of the service system.

Based on the same inventive concept, one or more embodiments of the present specification further provide a standardized device for driver invocation of self-service terminal equipment, which can be divided into the following modules according to the functions thereof, including:

the standard library generation module is used for respectively packaging the respective drives of the self-service terminal equipment of different models into the driving standard libraries with the same names;

and the standard library reference module is used for inquiring a preset configuration library for target self-service terminal equipment in the self-service terminal equipment with different models configured in the background when the service system is initialized, generating a reference path of the driving standard library of the target self-service terminal equipment based on the model and the MAC address of the target self-service terminal equipment, and deploying the driving standard library of the target self-service terminal equipment under the reference path for the service system to reference.

Based on the same inventive concept, one or more embodiments of the present specification further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the standardized method for driving and calling the self-service terminal device can be implemented.

Based on the same inventive concept, one or more embodiments of the present specification also provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute a self-service terminal device driver invocation normalization method.

As can be seen from the above description, the self-service terminal device driver provided in one or more embodiments of the present disclosure calls a standardized method and related devices, which can obtain a standard interface and a standard library that conforms to its definition, so that a business system loads the standard libraries of different equipment vendors in a non-intrusive manner; therefore, the driver and the upgrade thereof are compatible with the original standard interface, the change probability of the standard library is reduced, the maintenance cost is reduced, and one-time realization and long-term operation are achieved.

Drawings

In order to more clearly illustrate one or more embodiments or prior art solutions of the present specification, the drawings that are needed in the description of the embodiments or prior art will be briefly described below, and it is obvious that the drawings in the following description are only one or more embodiments of the present specification, and that other drawings may be obtained by those skilled in the art without inventive effort from these drawings.

FIG. 1 is a flow diagram illustrating a method for implementing standardized invocation of drivers for self-service terminal devices in accordance with one or more embodiments of the present disclosure;

FIG. 2 is a flow diagram illustrating one or more embodiments of the present disclosure implementing a driver invocation criteria library;

FIG. 3 is a flow diagram illustrating the process of driving a reference to a standard library in accordance with one or more embodiments of the present disclosure;

FIG. 4 is a schematic structural diagram of a device for calling a standardization by a self-service terminal device driver according to one or more embodiments of the present disclosure;

fig. 5 is a schematic structural diagram of an electronic device implementing a standardized method for invoking a driver of a self-service terminal device according to one or more embodiments of the present disclosure.

Detailed Description

For the purpose of promoting a better understanding of the objects, aspects and advantages of the present disclosure, reference is made to the following detailed description taken in conjunction with the accompanying drawings.

It is to be noted that unless otherwise defined, technical or scientific terms used in one or more embodiments of the present specification should have the ordinary meaning as understood by those of ordinary skill in the art to which this disclosure belongs. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items.

As described in the background, different providers of self-service terminals have their own driver designs. However, the driver designs of different equipment manufacturers cannot run across the terminal platform, so that when the same service provider adopts different self-service terminal equipment, the same service provider needs to develop the equipment for many times, run in a multi-set system mode, and increase the maintenance cost. And when the omission is modified, experience inconsistency and even failure of partial machine type business transaction can be caused.

In order to solve the above problems, one or more embodiments of the present specification provide a standardized method for calling drivers of self-service terminal devices and related devices, where drivers of different devices are packaged into standard libraries with consistent method names and parameter names, and the corresponding standard libraries are called from a background according to the types of the devices for adaptation. So as to achieve the purpose of loading the standard libraries of different equipment suppliers by the business system in a non-invasive mode.

Referring to fig. 1, the steps of implementing the standardization of the driver call of the self-service terminal device include:

and S101, packaging the respective drives of the self-service terminal equipment of different models into respective drive standard libraries with the same name.

Step S102, when the service system is initialized, for a target self-service terminal device in the self-service terminal devices with different models configured in the background, a preset configuration library is inquired based on the model and the MAC address of the target self-service terminal device, a reference path of the driving standard library of the target self-service terminal device is generated, and the driving standard library of the target self-service terminal device is deployed under the reference path for the service system to reference.

Referring to fig. 2, one or more embodiments of the present disclosure provide a standard library generation method, including the following steps:

and step S201, acquiring the use mode of the new hardware.

In this step, the working mode and function of the driver of the newly added self-service terminal device need to be known, and the definition of the standard library for the newly added hardware is conveniently carried out according to the existing standard library.

And S202, learning the drive design of the hardware plug-ins of different equipment vendors.

In this step, taking a bank card reader as an example, the bank card reader driver relates to two aspects of operation action and bank card type: the operation action relates to the steps of opening an inlet, sucking a card, reading the card, withdrawing the card, taking the card and the like; it is necessary to know whether the driver layer provides an event for each operation to be notified. The bank card type can be divided into a magnetic track card and a chip card, and whether the driving is supported or not needs to be known. The drive design is only packaged with sufficient knowledge.

And step S203, abstracting different drivers.

In this step, taking a bank card reader as an example, the user operation behavior may be divided into multiple types, but the usage scenarios such as card insertion, card reading, card fetching and the like are combined, and the effect is that the next service scenario is triggered in each operation step, so that the operation steps can be abstracted into a uniform interface and notified in the manner of identification codes. For example, the operation action, for opening the entry, completion of suction, completion of reading, completion of card return, and completion of card fetching, can be defined as "call back event in operation". Only one in-operation callback interface needs to be abstracted, then judgment is carried out through the return code, and the corresponding business process is triggered.

And step S204, defining a standard interface.

In this step, the following principles are followed when defining the standard interface:

the standard interface field should indicate whether it is necessary, i.e. whether it is necessary for the driver call;

each interface does not require more than one active interaction action by the user;

each interface has a synchronous or asynchronous ending method;

each interface can prompt the operation result of the service system through an ending method;

each interface should be reserved with an extensible field or mark to allow fine-grained service processing for special equipment;

each interface is compatible with various parameters required by different driving devices; taking a printer as an example, printers provided by different equipment vendors, or drivers provided by the printers, may not support perfect printing functions. Such as triggering duplex printing, printing multiple copies, printing from a specified page number a to a specified page number B, etc., which may only be supported in part on each device. But the standard interface is defined by defining all the interfaces and assigning default values to the non-blocking parameters. When the driver does not support, then its function is not called or an exception is returned.

And step S205, realizing a standard library aiming at different device drivers.

In this step, according to the interface document generated by the interface definition process in step S204, the interface document is implemented as different standard libraries for different device drivers, and the standard libraries need to conform to the following characteristics:

the method names in different driving standard libraries are consistent.

The parameter names that drive the same method are consistent.

The input parameter and the output parameter of the same method are driven to be consistent in different ways; the standard library should give a default value at the entry location, and when the device provided on the device does not support the specified function, an unsupported tag value should be reserved as a parameter to ensure the integrity of the entry structure. In the same way, if the device driver cannot provide the specified parameters during interface callback or synchronous return, a default value is given, so that the parameters are consistent.

The logic of the use scene of different driving the same method is in accordance with the interface definition; that is, when the service layer uses the standard interface, only the effect provided by the standard interface itself should be considered, and the bottom layer difference possibly brought by different drivers is shielded. For example, when reading an identity card, different drivers may have a difference between synchronous reading and returning or asynchronous reading and returning, but if an interface is defined as asynchronous returning, a subsequent method is also triggered in the standard library by a method call, and a read result cannot be returned in a form of synchronously calling a return parameter, so as to ensure that a service layer is not moved.

The standard library generation method expressed in the above embodiment can define a set of parameters that the target device can be compatible with various types of drivers by specifying the range of the standard interface, and divide the parameters into appropriate granularities, so that the parameters can be guaranteed to be normally ended when the parameters are called by the service system. The interface should reserve processing fields for possible extensions for subsequent self-service terminal device upgrades.

By limiting the realization of the standard library, the part of the driving method which is irrelevant to the user interaction and has too fine granularity is encapsulated, so that the standard library does not need to pay attention to the calling of the bottom layer, and the development cost of a service system is reduced.

Referring to fig. 3, one or more embodiments of the present specification provide a standard library call method, comprising the steps of:

and S301, forming a standard library js file.

In this step, standard libraries formed by drivers from different vendors are defined as referenceable js files with the same name.

And step S302, configuring the device type.

In this step, each device sets the device provider type in the management background of the service system. And simultaneously, when the service system is started, generating a standard library reference path according to the type of the equipment provider. In the process of system initialization, the equipment to which the equipment belongs is inquired in a configuration library through the MAC address of the equipment supplier of the uploading machine so as to obtain a part of path splicing of the equipment. And assuming that the reference path is/js/devices/XXX/devices.js, wherein XXX is a path needing to be spliced, replacing XXX with a value returned by the interface to obtain a js deployment path, and dynamically introducing the js deployment path to obtain a standard library corresponding to the local computer.

And step S303, deploying the reference standard library file.

In this step, the driving standard library of the corresponding device is deployed under the reference path confirmed in step S202, and the corresponding standard library is introduced into the business system.

And step S304, starting the service system.

In this step, after the standard library is introduced, the service system can be started, and the user can use the self-service terminal.

It can be seen from the above embodiments that, for different vendors and different hardware plug-ins, this procedure can be adopted to form a standard interface calling manner. Through the uniform specification of the file name and the method name, the service system can only identify the driving standard library which is used by the equipment. Because the method names of the standard libraries are consistent, the corresponding method can be obtained from the quoted standard library when the service system calls, and the method is the method encapsulated by the native driver, so that the hardware calling can be successful. And the implementation cost is not increased by a remote management mode. Since the self-service terminal is generally provided with the corresponding management background, the corresponding parameters are only required to be added when the self-service terminal issues the management background.

It should be noted that the method of one or more embodiments of the present disclosure may be performed by a single device, such as a computer or server. The method of the embodiment can also be applied to a distributed scene and completed by the mutual cooperation of a plurality of devices. In such a distributed scenario, one of the devices may perform only one or more steps of the method of one or more embodiments of the present disclosure, and the devices may interact with each other to complete the method.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Based on the same inventive concept, corresponding to any embodiment method, one or more embodiments of the present specification further provide a self-service terminal device driver invocation standardization apparatus.

Referring to fig. 4, the self-service terminal device driver invoking standardizing apparatus includes:

the standard library generation module 401 encapsulates drivers of different devices into a driver standard library.

When the service system is initialized, the standard library referencing module 402 queries a preset configuration library for a target self-service terminal device of the self-service terminal devices of different types configured in the background based on the type and the MAC address of the target self-service terminal device, generates a referencing path of the driving standard library of the target self-service terminal device, and deploys the driving standard library of the target self-service terminal device under the referencing path for the service system to reference.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, the functionality of the modules may be implemented in the same one or more software and/or hardware implementations in implementing one or more embodiments of the present description.

The device of the foregoing embodiment is used to implement the corresponding self-service terminal device driver invoking standardized method in the foregoing embodiment, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.

Based on the same inventive concept, corresponding to any of the above embodiments, one or more embodiments of the present specification further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the standardized method for driver invocation of the self-service terminal device according to any of the above embodiments when executing the program.

Fig. 5 is a schematic diagram illustrating a more specific hardware structure of an electronic device according to this embodiment, where the electronic device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.

The electronic device of the above embodiment is used to implement the corresponding self-service terminal device driver invoking standardized method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.

Based on the same inventive concept, corresponding to any of the above-described embodiment methods, one or more embodiments of the present specification further provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the self-service terminal device driver invocation standardized method according to any of the above-described embodiments.

Computer-readable media of the present embodiments, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the self-service terminal device driver invoking standardized method according to any embodiment, and have the beneficial effects of the corresponding method embodiment, which are not described herein again.

Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the spirit of the present disclosure, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present description as described above, which are not provided in detail for the sake of brevity.

In addition, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown in the provided figures, for simplicity of illustration and discussion, and so as not to obscure one or more embodiments of the disclosure. Furthermore, devices may be shown in block diagram form in order to avoid obscuring the understanding of one or more embodiments of the present description, and this also takes into account the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the one or more embodiments of the present description are to be implemented (i.e., specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that one or more embodiments of the disclosure can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative instead of restrictive.

While the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic ram (dram)) may use the discussed embodiments.

It is intended that the one or more embodiments of the present specification embrace all such alternatives, modifications and variations as fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of one or more embodiments of the present disclosure are intended to be included within the scope of the present disclosure.

Claims

1. A self-service terminal device drive calling standardization method without service system intrusion comprises the following steps:

2. The method according to claim 1, wherein in the respective driving standard libraries, method names of the same method are consistent, parameter names of the same method are consistent, and in-going and out-going parameters of the same method are consistent.

3. The method of claim 1 or 2, wherein the library of drive criteria is a referenceable js file.

4. The method according to claim 1 or 2, wherein the packaging of the respective drivers of different models of self-service terminal devices as respective driver standard libraries of the same name comprises:

and abstracting the corresponding drive according to the application scene of the self-service terminal equipment.

5. The method according to claim 1 or 2, wherein the packaging of the respective drivers of different models of self-service terminal devices as respective driver standard libraries of the same name comprises:

defining a standard interface for each of said drives;

and respectively packaging each drive into each drive standard library according to an interface document generated when the standard interface is defined.

6. The method of claim 5, wherein application scenario logic of the same method in the respective driver criteria libraries conforms to the definition of the standard interface.

7. The method of claim 5, wherein the standard interface follows the following principles:

the standard interface field needs to indicate whether the standard interface field is necessary for calling the driver;

the standard interface cannot require more than one active interaction action by the user;

the standard interface needs a synchronous or asynchronous ending method and can prompt the operation result of the service system through the ending method;

the standard interface needs to be reserved with an extensible field or mark;

the standard interface is required to be compatible with the access parameters required by the self-service terminal equipment of different models.

8. A self-service terminal device driver calling standardization device comprises:

the standard library generation module is used for packaging the drives of different devices into a drive standard library;

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable by the processor, characterized in that the processor implements the method according to any of claims 1 to 7 when executing the computer program.

10. A non-transitory computer-readable storage medium storing computer instructions which, when executed by a computer, cause the computer to implement the method of any one of claims 1 to 7.