Сообщения, отправленные пользователем: MalkovichAP

Александр!

Я установил на своем домашнем компьютере для просмотра первую версию сервера Госветнадзора "БУГ" на момент декабря 2004 года.
Т.е. то, что у нас было более 5 лет назад....
Права я ограничил и на сервере и на клиенте, чтобы поменьше возможностей было, постепенно буду права добавлять и можно отработать всю технологическую цепочку.

Да, для этой версии используйте IE 6 или выше.

Сервер:
http://180.by/v/

Вход: Имя: Осминин
Пароль: 1

И первую версию клиентской части, тоже декабрь 2004.

Клиент: используйте IE 6 или выше.

http://180.by/vc

Вход: Имя: Осминин
Пароль: 1
Клиент может быть перенастроен на любого участника системы, так что можно проверить работу системы входя в нее под разными участниками системы.

И на сервере и на клиенте я огранил права, чтобы для начала меньше вопросов было. Посмотрите и если что пишите на a_malk@mail.ru или на MalkovichAP@gmail.com
Или в Scype: malkovichap
Следующие версии (2007, 2010 г.г.) я подготовлю и поставлю позже. В них мы просто более быстрые и профессиональные диалоги стали делать, а суть от этого не поменялась.

А http://180.by - это наша справочная служба по лекарствам в Минске.

1. Нет, не просто СУБД, опишите весь технологический стек.

На скрвере:
Центарльная база данных
Сервер приложений (Программы на Cache Object Script)
Web cервер Apache (для тонких клиентов)

Сервер транспортной технологической подсистемы (для толстых клиентов)

На клиенте:
1.Толстый клиент
База данных клиента
Сервер приложений клиента
Клиент транспортной технологической подсистемы
IE - приложение клиента
2.Тонкий клиент
IE - приложение клиента

Что ставится на клиентские машины? Подразумевается офлайновая работа в браузере как аналог Google Gears? Мы для офлайновой работы используем отдельное десктоп-приложение.

На клиенте:
1.Толстый клиент
База данных клиента
Сервер приложений клиента
Клиент транспортной технологической подсистемы
IE - приложение клиента
2.Тонкий клиент
IE - приложение клиента

Вопрос про многосерверную архитектуру. Предполагается многосерверный центральный сервер или несколько распределенных серверных площадок? Нас интересует второй вариант.

Для этого иы придумали специальную технологию виртуальных ресурсов, которая позволяет просто создать при необходимости несколько распределенных площадок, а центральный сервер будет аккумулировать все (если в это будет необходимость) или только то, что ему достаточно и необходимо.
А чать информации может находится на серверах нижнего уровня и они, конечно должны иметь зеркало у себя.

3. Можно получить тестовый доступ к вашему приложению?

Можно конечно. Я создам для Вас учетную запись и сообщу в ближайшее время.

А здесь я прикреплю небольшой текст, который поясняет нашу технологическую цепочку (когда-то писал...):

Как это у нас:
1. В установленном порядке заявитель продукции формирует заявку.
(старый установленный порядок в связи с автоматизацией должен быть изменен на новый)

Формирование заявки может формироваться 2 способами:
• Подача заявки на бумажном носителе или на дискете. В этом случае заявка является произвольным и не четко формализованным документом.
• Подача заявки через сеть Intenet/Intranet из клиентского рабочего места (например, Internet Explorer или др.). Подавать заявку через сеть Internet имеет право только тот пользователь, который зарегистрирован в системе как участник системы, который может подавать заявки.
2. Заявка поступает в “Подсистему заявок центральной базы данных”.
Способы поступления в “Подсистему заявок”
• автоматически, если заявка была подана через сеть Internet/Intranet
• ручной ввод оператором, в случае, когда заявка была подана на бумажном носителе или на дискете
• сканирование установленного специального бумажного варианта заявки с последующим автоматическим распознаванием
3. Подсистема ввода заявок базируется на подсистеме специального электронного документооборота (в будущем такая система должна быть использована для всего документооборота ГосВетНадзора), т.е. заявка проходит все необходимые состояния до утверждения (от “подано”, “подписано” и “создано разрешение”).
Подробнее о системе документооборота см. документацию по системе документооборота. При этом работа с заявкой разграничена как по доступу, так и по пользователям. Т.е. заявка в состоянии “подана” не доступна специалисту, который проверяет и готовит к подписанию.
4. После решения всех подготовительных вопросов заявка подписывается руководством Главка ветеринарии или ГУ “Госветнадзор”. На бумажную копию заявку ставиться соответствующая печать (штамп).
При необходимости формируется выходная форма заявки в установленной форме.
5. После подписания заявки, она автоматически регистрируется в Центральной Базе Данных Разрешений и создается соответствующее ей «разрешение».
ВСЕ разрешения хранятся только в центральной базе разрешений.
Все зарегистрированные заявки в Главке ветеринарии имеют исходящий номер 10-2/ порядковый номер заявки на день регистрации.
Все зарегистрированные заявки в ГУ “Госветнадзор” имеют исходящий номер 10-4/ порядковый номер заявки на день регистрации.
Так как Разрешения хранятся только в одном месте, таким образом, ликвидируется дублирование регистраций разрешений.
Разрешения доступны пользователям системы согласно тех прав, которыми их наделил Администратор, т.е. каждый видит только то, что относится к его данным.
6. Заявитель узнает номер разрешения и дату его регистрации, позвонив по телефону по месту регистрации заявки, обратившись непосредственно в организацию выдающую разрешения или послав SMS сообщение на определенный номер.
Так же Заявитель может узнать номер разрешения и дату его регистрации и по сети Internet либо Intranet через клиентское ПО. В этом случае пользователю будут доступны только те заявки, который он подал. По выбранной заявке он может узнать номер разрешения.
7. Все разрешения при изменении их состояния в центральном сервере на «утвержденное» автоматически ставятся в очередь на передачу всем участникам Системы, которых эти разрешения касаются и немедленно передаются по доступным каналам связи (Internet, коммутируемые каналы связи и др. на ПКВП и ПП и другие места в которых могут нахидится зарегистрированные участники системы.
При этом инициатива о передачи информации о разрешениях исходит именно от ПКВП и ПП (или других участников системы, которые работают с центральной базой разрешений): инициатива - это либо запрос от клиента или просто клиент подключен к каналу связи, а у сервера для него есть информация для передачи.
Следует заметить, что ПП является таким же пользователем, как и любой ПКВП, хотя ПП подчинен ПКВП организационно.
Информация о разрешениях передается на клиентские места не вся, а избирательно: только в том случае, если клиентское место (участник системы) указан в списке пунктов провоза (оформления).
В особых случаях администратор системы может разрешать (наделять правами доступа) участников системы для доступа к интересующей их информации в центральной базе разрешений такой доступ отражается в подсистеме аудита для контроля за этими действиями.
8. На клиентском рабочем месте (ПП, ПКВП) вводятся оформления по переданным разрешениям (при прохождении грузов), если была успешной проверка на наличие всей документации на груз, его соответствие, ветеринарно-санитарное состояние транспортного средства и груза.
После создания оформлений, информация о прошедшем грузе (оформления) ставится в очередь на передачу у клиента и передается автоматически на центральный сервер при наличии TCP-соединения с центральным сервером разрешений (как только будет ближайший сеанс связи, а если связь постоянна, то передача осуществляется немедленно).
Эта процедура происходит опять же по инициативе клиентской стороны (частота сеансов связи зависит от организационной составляющей системы).
На сервере эта информация принимается и обрабатывается, и заносится в базу данных.
Назад на клиентское рабочее место отсылается ответ с кодом обработки поданного запроса и телом (информацией) ответа в случае необходимости.
9. При любом обновлении информации в разрешении о прошедшем грузе формируются автоматические запросы на передачу изменений от центрального сервера на клиентские места, которые указаны в списке пунктов провоза/оформления, для принудительного обновлении этой информации о разрешении на них. На каждый запрос в ответ система получает ответ и все это логируется и доступно администратору для контроля и для клиента на его стороне.
Таким образом, получается схема: “Что-то изменил в разрешении– стало известно центральной базе данных и всем, кто к этому имеет отношение”.
10. От центрального сервера могут поступать периодические запросы (имитация запросов от участников системы) на обновления справочной информации на клиентских рабочих местах.
11. На центральный сервер могут подаваться запросы от участников системы на получение любых установленных форм отчетности.
12. Возможные нарушения:
• одновременный провоз груза на разных ПКВП/ПП, что может приводит к превышению разрешенного на провоз количества
•
Методы реагирования на такую ситуацию:
• если оформление отослано на сервер (наличие TCP-соединения – сеансе связи) – сразу же ВСЕ и обнаружится. Дальше реакция администратора в установленном для такой ситуации порядке.
• при первом же TCP-соединении (сеансе связи) повторяется предыдущий пункт
При нарушении целостности данных (превышение разрешенной на провоз суммы, либо прохождении неразрешенного груза) выдается сообщение Администратору системы.

P.S. Но это не все, остальное можно дописать позже....

1. Для сервера в настоящее время мы используем пост-реляционную СУБД Cache. (Возможно портирование математики сервера на GT.M - open source, что бы уменьшить лицензионную нагрузку при необходимости)

2. На клиентах: Субд Cache (сейчас) (для клиентов но мы также предусматриваем возможность использования DOM Storage, HTML 5 для уменьшения лицензионной нагрузки при необходимости)

3. Технологисечкий транспорт и специализированный протокол обмены отлажен так, что выступает, как независимая подсистема легко интегрируемая с очень простыми функциями с точки зрения использования для полльзователей

4. Мы готовы на сотрудничество, тем более, что чувствуем, что действительно можем быть полезны.

5. Формат взаимодействия можно обсудить, после ознакомления с Вашей системой и с нашим подходом. Найти точки взамодействия, где мы можем быть Вам полезны.

1.автоматизация выдачи решений (полная автоматизация или в виде СППР);
А встроенная система документооборота? У нас так сделано... Даже есть еще один вариант.
2. повышение надежности центрального сервера (создание нескольких территориально распределенных серверных площадок);
У нас многосерверная архитектура поддерживается изначально, а на ПКВП и переходах в локальных сетях клиентские рабочие места, которые могут подключаться независимо друг от друга к центральному серверу и закачивать и отдавать необходимую информацию автоматически и работать после этого автономно, до следующего сенса связи, а если связь условно постоянна, то взаимодействие происходит абсолютно прозрачно для польхователей в псевдо-online режиме.
3. внедрение ЭЦП.
Наш технологический транспорт для клиентов и сервера поддерживает возможность закрытия каналов (создание VPN сети для всех участников системы). И для ЭЦП тоже все готово...есть опыт, специалисты, решения.

Мы разрабатываем аналогичную систему в РБ. Кроме on-line через браузер Cистема работает прозрачно для пользователя в режиме on-line/off-line с локального клиента и автоматически закачивает и передает нужную информацию.
Этот было сделано еще 2003-2004 гг. В 2005 надеялись развернуть в РБ, но по независящим от нас обстоятельствам этот процесс притормозили... Но Систему развивали и поддерживаем до сих пор. Многие технические, которые Вы планируете решать, у нас уже есть, вот мы и подумали, что наш опыт может Вам пригодится.

ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНАЯ СИСТЕМА ГОСУДАРСТВЕННОГО ВЕТЕРИНАРНОГО НАДЗОРА ПО КОНТРОЛЮ ЗА ВЫВОЗОМ (ЭКСПОРТ), ВВОЗОМ (ИМПОРТ) И ТРАНЗИТОМ ПОДКОНТРОЛЬНЫХ ГРУЗОВ
(ИВС ГОСВЕТНАДЗОРА «БУГ»).

Автоматизация процесса формирования разрешений на ввоз/вывоз продукции в/из страны и передача их на ПКВП/ТВСУ, осуществление автоматизированного контроля за прохождением грузов на погранично-контрольных ветеринарных пунктах. Пользователям системы предоставлена возможность анализа накопленной информации в центральной базе данных на основе OLAP технологии.

Основные функции системы:
• Ввод заявок и утверждение разрешений на ввоз/вывоз/транзит в центральную базу
• Просмотр текущего статуса состояния заявок пользователем.
• Автоматическая рассылка утвержденных разрешений только тем адресатам (участникам системы,погранпереходы, ПКВП ...), которых эти разрешения касаются.
• Оформление провозов на границе (погранпереходы, ПКВП)
• Автоматическая передача информации о провозах в центральную базу данных и немедленное извещение об изменениях в центральной базе всех участников системы, которых эти изменения касаются
• Оформление провозов по разрешениям, выданным другими организациями, имеющими соответствующее разрешение.
• Выдача любой отчетной информации по OLAP технологии. Критерии запросов определяются пользователем системы без дополнительного программирования.

Система полностью соответствует требованиям ТЗ разработанного в Госветнадзоре РБ для WEB-системы «Информационно-вычислительная система государственного ветеринарного надзора по контролю за вывозом (экспорт), ввозом (импорт) и транзитом подконтрольных грузов»
Внедрение системы в Минсельхозпроде РБ – это внедрение готового решения, которое позволит создать высоконадежную корпоративную систему для Госветнадзора РБ. Что позволит значительно снизить затраты на разработку, развертывание и, самое главное, на сопровождение системы и получить достоверную информацию в реальном режиме времени.
В системе ИВС ГОСВЕТНАДЗОРА БУГ пользователи могут работать в двух режимах с полной функциональностью:
1. Обычный Браузер (тонкий клиент) – online.
2. Также обеспечивается прозрачная работа как в on-line, так и в off-line режиме (через обычный Браузер, но клиентская часть, установливается у пользователя, взаимодействует с центральным сервером по специализированному протоколу на основе http протокола в xml формате). Гарантированную автоматическую доставку пакетов по любым каналам связи обеспечивает технологическая транспортная подсистема. Этот режим работы делает системы высоконадежной и обеспечивает оперативное обслуживание клиентов, даже если связи с центральным сервером временно нет. При появлении связи клиент и сервер автоматически обмениваются необходимой информацией.

Здравствуйте, уважаемые разработчики!

У меня есть предложения по развитию автоматизированной системы АРГУС.

С кем можно их обсудить?