Один способ передачи данных между базой ФБП и удаленной UltraH



Posted by Анатолий Анимица on August 29, 2000 at 23:27:46:

In Reply to: при настройке posted by витаминная станция краснодар on August 07, 2000 at 02:23:29:

Витаминная станция (Краснодар) запросила способ передачи данных от клиент-сервера ФБП
удаленной ФБП UltraH, работающей на машине с очень ограниченными ресурсами, что не
позволяло предложить один из известных способов доступа сервер-сервер через их каталоги
обмена.

Предлагалось использовать в качестве файла-носителя данных extrd.dat. Это невозможно
реализовать из-за отсутствия надежного разделения доступа к extrd.dat между работающим
сервером первой машины (главной базы) и программой копирования для второй машины (Ultra).

На самом деле этим проблемы не исчерпываются. Extrd.dat в таком режиме использования
исключается для второй машины как среда хранения информации - она не может быть сохранена
в следующем сеансе смены extrd.dat с новой порцией информации от первой машины.

Предлагается другой вариант решения, основанный на следующих соображениях.
Пpежде всего пеpепишите аpхив с пpимеpом.

1. Какая информация поступает на вход Ultra второй машины и можно ли ее использовать?
1) acnt.a3p. Не годится, так как доступен на запись на второй машине и не сохранит
изменения при передаче нового варианта
2) *.f3p Не годится по той же причине. Был бы месяц 0, другое дело.
3) extrd.dat Не годится. Самому тогда некуда будет писать (для долгого хранения).
4) extra.b Не доступен второй машине по записи, пригоден для передачи данных, но
порождает экстрапараметры, расходующие ресурсы второй машины без пользы
для дела - в значениях на конец дня в течение отчетного года.
5) *.rpt Отличное решение. Достаточно генерировать на первой машине файл fcstart.rpt
и передавать его второй машине, а та, в свою очередь, выполняла бы его в
качестве одного из первых файлов-коэффициентов. Решение требует генерации
кода программы и в этом варианте не рассматривается, несмотря на его сугубую
привлекательность. Хотя при желании вполне можно попробовать.
6) facts.b Подобно extra.b, не доступен для записи на второй машине, не требует вторичных
ресурсов, надежно клонируется и представляется идеальным передатчиком данных.
Случайная повторная запись одного и того же факта в клонируемый facts.b легко
распознается и обходится средствами ФБП на второй машине.


2. Какие проблемы нужно решить для реализации метода 1.6) ?

1) хорошо бы обеспечить блокирование повторной записи в facts.b при включении пересчета на
первом сервере. Проблему можно реализовать так, как это сделано в генерации ПД на сервере
ФБП - c помощью *.des файла. Но *.des не доступен по чтению. Можно записать индекс (сигнатуру)
в extrd.dat первой машины (сервера). Но надежность extrd недостаточна или требует для ее
повышения администрирования базы сервера (резервное копирование, слежение за версией,
восстановление и т.п.).
Поэтому применен самый простой способ: передаваемая информация дописывается в клон facts.b
второй машины, расположенный в подкаталоге \FACTSB каталога обмена сервера (первой машины)
и после записи порции данных этот клон facts.b передается в базу второй машины. Разумеется,
базу на второй машине нужно будет перезапустить, но, поскольку там Ultra - это не задача.

2) на второй машине мы имеем некоторое количество фактов на входе, которые надо обработать. И
не делать этого дважды. Как? Генерация вторичных фактов вида "это уже сделано, забудьте" не
решает проблемы, так как при перезапуске базы второй машины все это "забудьте" вычисляется
сначала.
Поэтому применен простейший способ: в каждом факте клона facts.b присутствует поле штампа 3
операции первой базы (и, также, номер документа - например, заявки). Обработанный на второй
машине факт запоминается в ее extrd.dat и при последующих пересчетах базы второй машиной
просто пропускается.

3) не так просто смоделировать поведение ФБП при записи фактов (там простой текстовый формат),
s='(>> file fi)'
но средства записи в файл ^^^^^^^^^^^s не позволяют сделать это точно, нечем вывести разделитель
между фактами ODOA ([ch 13]+[ch 10]), printstr не умеет выводить в файл.
Тем не менее, если немного подумать, это решается.

4) квитанция о приеме-исполнении - в общем, не так необходима, но полезна. Эта часть не решена,
но путь известен - можно прямо через каталог обмена передать серверу первой машины, а можно
ей подменить facts.b ее собственным плюс набор квитанций об обслуживании.

Из чего состоит пример.

Две абсолютно одинаковых базы данных (1 и 2), с каталогами обмена внутри каталогов данных, что
позволяет обойти [dir 1] в Ultra, с одинаковыми cas.rul, но, естественно, набор операций
на разных машинах должен быть разным - на первой "создать заявку" и "записать", а на второй -
выполнить, так что на практике лучше на второй машине от греха лишние ветки отрезать.

Заодно в пример включены несколько утилит *.rpt, в частности, файл methods.rpt - фрагмент
уже довольно обширного набора методов и подпрограмм для ФБП, позволяющий не изобретать велосипед
каждый раз заново.

Некоторые пояснения даны в комментариях к программе и здесь не дублируются.


Как с этим работать.

Разместите базу 1 на первой машине и запустите на ней сервер (например, на 2 имени
fnt2.exe - проверялось на fnt10316.exe под Win98) и клиент с именем S и паролем 111
(если не менять _rights_.fbp).

Разместите на второй машине базу 2 и приготовьте ее для работы с UltraH (16 разрядной,
если памяти меньше 32 МБ, а можно и Ultra32, но в этом случае - скорее всего - вся
эта технология проще реализуется на взаимодействии серверов через их каталоги обмена).

Поместите в каталог \FACTSB файл facts.b из каталога \OLDFACTS. Там он пустой, а так
можно взять настоящий facts.b от второй базы - но без клонов заявок.

Теперь выполните группу или несколько групп операций "создать заявку" и одну операцию
"записать заявку".

Перенесите полученный facts.b в каталог данных второй машины, в в \FACTSB первой
скопируйте facts.b из \OLDFACTS. Тем самым первая машина готова к следующей порции
заявок.

На второй машине постройте баланс и создайте еще одну операцию "выполнить заявку",
получите ее первичный документ. Посмотрите результат.

Блокировка повторной генерации осуществляется записью индексов (сигнатур) в extrd.dat
второй машины. Это можно увидеть, если просто открыть extrd.dat в редакторе, например,
FAR.


Выводы. Приведенный пример нельзя, конечно, использовать на практике, так как он сильно упрощен:
формат факта утрирован, формат операции тоже, отсутствует обработка заявки в достаточно полном виде,
и так далее. Но для программиста и опытного пользователя ФБП это уже не составит проблем.

Маленькие хитрости.

Если посмотреть внимательно текст файла fcznsv.rpt, легко видеть, как можно манипулировать
средствами работы со строковыми данными в языке F, как удобно располагать текст программы
на экране (чтобы можно было писать и в Ultra, и в клиенте Windows).

Иногда хочется удобно посмотреть, а что там такого написано в extrd.dat
Если запустить над каталогом данных программу aex.exe, она заменит нули в конце строк extrd.dat
на ODOA - и любуйтесь на здоровье. Толко нужно иметь в виду, что длина записи 12 байт
разрежет строку на 2 (только визуально).




Пpишедшие ответы: