Альтернативный заголовок вопроса: Как я могу перевести «Это программное обеспечение вызывает у меня мурашки по коже» на бизнес-обоснование, чтобы высшее руководство не покупало его?
Я работаю ИТ-отделом небольшой компании, которая в течение нескольких лет стабильно росла. Мы начали с QuickBooks, перешли на другую систему бухгалтерского учета и теперь находимся на рынке среднерыночных ERP-систем, которые являются немного более всеобъемлющими и настраиваемыми. В настоящее время мы оцениваем ERP-систему, написанную на Visual FoxPro 9, и у меня плохое предчувствие, но я не могу точно перечислить, почему это так.
Он состоит из нескольких модулей: модуль бэк-офиса и веб-модуль - вот два, которые нас интересуют. Модуль бэк-офиса содержит обычные функции ERP для заказов / выполнения / доставки / учета. Веб-модуль управляется той же базой данных FoxPro, указывая IIS на компонент .NET, открывающий базу данных с другого компьютера с использованием пути UNC. Об этом я тоже не знаю, но это пока отдельная тема.
Меня беспокоит то, что система «устанавливается» следующим образом:
1. Create a top-level folder on a server.
2. share that folder with appropriate users and groups as \\server\erp
3. unzip the .exe and dlls and \data folder in the shared folder
4. map \\server\erp to a drive on client computers
5. create a shortcut to the \\server\data\erp.exe on client desktops.
6. double click on shortcut! You’re ERPing! (after some other minimal setup)
.Exe использует доступ к файлам в подкаталоге \\ server \ data для заполнения форм и т.д., как обычно.
Я обеспокоен тем, что одновременные пользователи (25 или более), обращающиеся к одному .exe, который обращается к файлам через сетевую файловую систему (cifs) для выполнения функций базы данных, кажется ... подозрительным. Каждая другая система, которую я видел, использует отдельный движок базы данных, либо доморощенный (что достаточно плохо), либо что-то вроде SQL Server, Oracle, даже PostGreSQL или черт возьми, даже MySQL для обработки доступа к данным, но этот просто один файл .exe в общей папке, запускаемый непосредственно из этой общей папки на рабочем столе каждого клиента. Похоже, что это неэффективно или, по крайней мере, неэлегантно и вызовет большой избыточный сетевой трафик. Файл .exe имеет размер около 10 МБ и находится на сервере, открывает файлы .dbf, находящиеся в соседнем каталоге \ data. Продавец спрашивал, есть ли у нас гигабитная сеть (у нас есть), и это показалось ему очень важным ... теперь я понимаю, почему он спрашивал.
У меня нет глубокого опыта разработки, но мне кажется, что у вас должен быть отдельный механизм базы данных, который связывается с клиентами через именованный канал или сокет TCP / IP, или, по крайней мере, какой-то бинарный сетевой протокол, если ничего больше. Использование общего доступа через netBIOS (вы вводите UNC-пути в базу данных как свойства) кажется неправильным, потому что вы не столкнетесь с проблемами блокировки файлов, если, например, два пользователя хотят открыть одного и того же клиента в A / R? Я просто слишком осторожен? Неужели это стандартная практика, как утверждает производитель? У меня нет большого опыта работы с более крупными системами бухгалтерского учета, подобными этой. В нашем текущем пакете используется модель клиент-сервер с обработкой файлов движком БД, а затем пользователи, запускающие программное обеспечение на своих машинах, общаются с ним через сеть. Я ошибаюсь, полагая, что что-то более продвинутое будет иметь аналогичный интерфейс?
То, что вы описали, несомненно, вызывает у меня беспокойство по двум причинам:
Тот факт, что представитель настаивал на использовании гигабитных сетей для такого небольшого приложения. Может оказаться, что это не окажет никакого практического влияния на вашу сеть, но это заставит меня серьезно задуматься о дизайне приложения. ERP-система на 50 пользователей не должна беспокоить 10-мегабитную линию, не говоря уже о гигабитной.
Последствия для безопасности процесса установки были бы для меня нарушением сделки. Это система, которая хранит информацию о клиенте (и, вероятно, платеже клиента). Пользователи будут запускать exe-файл в виде короткого замыкания, что означает, что 25-50 экземпляров этого exe-файла будут работать под учетными данными пользователя на их рабочих станциях. Эти процессы имеют прямой доступ и запись в файлы общей базы данных на такая же доля. Это означает, что каждый пользователь по своей задумке должен иметь прямой доступ для чтения / записи ко всей вашей базе данных. Это ужасно с технической точки зрения и с точки зрения соблюдения требований безопасности.
Лично я бы пробежал милю от этого приложения только по последнему пункту. Я уверен, что люди, более знакомые с областями соответствия (или с FoxPro), могут прокомментировать дальнейшие действия.
Был там, сделал это.
Я признаю, что VFP9 выглядит немного устаревшим, но это проверенная технология.
Верьте или нет: VFP9 очень надежен в такой настройке. Это совсем не похоже на msaccess. Поначалу я тоже сомневался, но на практике проблем нет.
Дополнительный бонус: вы даже можете делать простые файловые резервные копии БД, пока ни у одного пользователя не открыто приложение, что хорошо, если у вас нет круглосуточного магазина.
Но вам нужна быстрая (не менее 100 Мб) локальная сеть между клиентами и серверами. (И, ради бога, поставьте на сервер сетевую карту 1G.) EXE-файл локальный или на сервере не имеет особого значения, любой из них будет работать нормально.
Как заявляли другие: для нелокальных пользователей вам нужна установка WTS. Рекомендуется делать это на отдельной машине, а не на самом сервере VFP9. (Конечно, с Hyper-V или VMWare обе машины могут быть виртуальными машинами на одном физическом сервере.)
Обратите внимание, что пользователям WTS может потребоваться изрядное количество оперативной памяти для каждого пользователя. Это немного зависит от эффективности запросов к БД и потребностей приложения.
Из того, что я видел, рабочие наборы от 100 до 200 МБ вполне нормальны для приложений vfp9, из которых около половины будет закреплено в физической ОЗУ. По моему опыту, от 20 до 30 пользователей на сервере WTS с 4 ГБ ОЗУ вполне выполнимы, если им не нужно запускать что-то еще в сеансе WTS. В зависимости от потребностей вашего приложения ваш пробег может отличаться.
У меня большой опыт работы с пакетом ERP Visual FoxPro 9, который работает более или менее одинаково - общий доступ к файлам на сервере, несколько клиентов с местный EXE и файлы поддержки, обращающиеся к общему ресурсу SMB. Набор данных для каждой компании в ERP - это сотни файлов DBF.
Что касается производительности, мы не видим никаких проблем - у нас много клиентов, использующих 30 или более клиентов на довольно стандартном сервере Windows, обращаясь к файлам DBF, которые могут иметь миллионы строк и более 1 ГБ. Если индексация и блокировка реализованы ERP правильно, тогда все эти числа в порядке.
Да, есть проблемы с безопасностью, если общий файловый ресурс заполнен файлами DBF. Я полагаю, это зависит от типа клиента, которому наша ERP-система продает, но за более чем 15 лет и с тысячами сайтов количество, которое, как я лично знаю, мы потеряли из-за этой настройки, может составить около 20. Эту проблему также можно обойти с помощью служб терминалов.
Вы абсолютно правы и в том, что вам придется использовать службы терминалов, возможно, через VPN, чтобы запускать их удаленно.
Кроме того, если вы в конечном итоге используете рассматриваемую ERP и у вас есть компьютеры с Windows 7 и Server 2008, убедитесь, что они находятся на SP1, поскольку в SMB возникла ошибка, которая привела к повреждению файлов индекса.