February 19, 2015 at 13:10

External equipment driver for 1C using the fiscal registrar Maria-301MTM as an example

    image
    When implementing projects on 1C, one often has to deal with various kinds of devices and their interface. As long as devices on the ancient RS232 exist, there will be a need for external components of this kind. As a rule, documentation comes with the device, which often contains a system of commands and a certain driver that is distributed “as is”. Very often drivers "as they are" leave to expect the best. I suggest a little dip into system programming and solve this issue for yourself once and for all.

    A wonderful article contains an example and a sufficient description of what's what, what, where to change. An example compiles. For a quick start, a great article. A similar example is freely distributed by 1C and is lying in a heap of junk on the ITS disk. Many times flashed in the eyes, but was laid on the far shelf with the label "must be studied."

    For simplicity, I will call the external component hereinafter the driver.

    1. The abandonment of OLE32 in favor of the Native API.
    Hard memories of registering the OLE32 component, and the horror of registering them under Windows 7, prompted the consideration that the driver should support the Native API. Registration of such an external component looks like:
    ПодключитьВнешнююКомпоненту(ИмяФайлаДравера, "prn", ТипВнешнейКомпоненты.Native);
ДемоКомп = Новый("AddIn.prn.Maria2");

    In this case, no actions of type regsvr32 are preliminarily. And as far as I know, OLE32 has not been Microsoft's flagship technology for a long time.

    2. Storage of the driver itself as part of processing or configuration.
    We insert the driver file into the 1C layout as binary data and, if necessary, unpack it into the user's temporary directory.
    Макет = ПолучитьОбщийМакет("Драйвер");
ИмяФайлаДравера = КаталогВременныхФайлов() + "AddInNewMaria.dll";
Макет.Записать(ИмяФайлаДравера);	
ПодключитьВнешнююКомпоненту(ИмяФайлаДравера, "prn", ТипВнешнейКомпоненты.Native);
ДемоКомп = Новый("AddIn.prn.Maria2");


    3. Implementation of the driver interface. Removal of the logic of commands to the 1C side.
    Initially, when writing a driver, the ideology of existing drivers was used. DemoComp.Make Something (Many times).
    ДемоКомп.NullCheck();
ДемоКомп.CancelCheck();

    In fact, the driver was repeated, of course, without restrictions imposed by the manufacturer. But this heredity was painful and pernicious. Once every half a year there is a need to add some teams, change existing ones.
    A universal RS232 port driver for 1C was written . It has been tested by the usb modem Huawei-1550 and with Maria. For this driver, you need to rewrite the service processing for 1C.
    After the next "improvement" the idea of ​​taking the logic of commands to the 1C side was born. The driver only deals with the implementation of the transport protocol. System programmers rejoice. Now the driver command looks like:
    ДемоКомп.Команда("NULL"); //печать нулевого чека

    And yes, to the delight of every programmer 1C Native API gives you the opportunity to call functions in Russian (Russian function aliases).

    4. Recording of the exchange protocol.
    To write the commands and reactions to the user’s maria.log file to the directory of temporary user files:
    ДемоКомп = Новый("AddIn.prn.Maria2");
ДемоКомп.Логирование();

    The time and type of event are written in the file: c - command; a is the answer; u is the connection; t is the number of cycles to obtain a response; e is an error.
    [20150210205009]t:   1    8
[20150210205009]u:эREADYю
[20150210205009]c:эSYNCю
[20150210205009]t:   1   29
[20150210205009]a:эWAITюэSYNCюэDONEюэREADYю
[20150210205009]c:эCNALю
[20150210205009]t:   1  141
[20150210205009]a:эWAITюэCNAL2013120510200020150210200500000000000000000000000000000000000000000000000000000000000000000000000020131205800000uюэDONEюэREADYю
[20150210205009]c:эUPAS1111111111‘в ¦Ґаю
[20150210205009]t:   1   22
[20150210205009]a:эWAITюэDONEюэREADYю
[20150210205009]c:эNREPю
[20150210205012]t:  18   52
[20150210205012]a:эWAITюэNREP5100	юэPRNюэSOFTREGISTюэDONEюэREADYю
[20150210205012]e:35


    Here is the minimum set of necessary to "earn." Now a little about the future:

    5. Other devices of this class.
    As planned, it’s not difficult to replace Mary’s transport protocol with a protocol like IKS. We could talk about a family of drivers. The skeleton itself of the basic necessary functions is ready.

    6. External events.
    In the procedures for implementing the transport protocol, it is worth switching to threads, and signaling the completion of the work of the team is done by an external event. I want to do just that, but a little something is missing: time or knowledge, or both. And the rock "already works like that", "do not touch it," slightly cools the ardor of the impulse.

    7. Collaboration.
    The plans include writing a simple web-service that would take commands, organize a queue of commands and redirect them to the device. Service processing in this case will look similar, the teams will not change. Only the initialization of the object will change.

    Link to the project on github
    The project consists of a Visual Studio project, demonstration of commands on 1C (in the managed application module) and a processing service for 1C.
    Tags:

    Also popular now: