Какова наилучшая стратегия объединения IntrAnet и веб-сайта?

Мне было интересно, есть ли у кого-нибудь понимание этого вопроса.

Небольшая предыстория:

Мы использовали Rails для перехода от старой системы на основе dBase и Visual Basic к созданию внутренней компании IntrAnet, которая выполняет такие функции, как печать этикеток, управление запасами, доставка и т. д. — в основном ERP.

Дилемма

Прямо сейчас нам нужно заменить старый клиентский веб-сайт, созданный на Java, который будет подключаться к нашей внутренней системе для использования нашими клиентами. Мы хотим иметь возможность извлекать информацию, такую ​​​​как запасы, размещение заказов, выписки по счетам, из нашей внутренней системы и отображать ее на сайте в режиме реального времени. Причина в том, что мы принимаем заказы на веб-сайте, по факсу и телефону, а иногда у нас есть посетители. Так что иногда (очень редко) даже короткая задержка обновления инвентаря на нашем старом Java-сайте заставляет нас размещать заказ в режиме ожидания, потому что мы продаем один и тот же товар 2 клиентам в течение получаса. Обычно это исправляется в течение одного дня, но мы хотим избежать этого в будущем.

Актуальный вопрос

Есть ли у кого-нибудь предложения о том, как сделать это лучше?

Вот три варианта, которые я вижу:

a) Создайте отдельное приложение Rails на веб-сервере, которое будет подключаться к той же БД, к которой подключается наше внутреннее приложение.

  • +++ Плюсы: Оперативные данные - то же самое, что видят наши внутренние приложения, т.е. заказы создаются в режиме реального времени, запасы истощаются сразу

  • --- Минусы: Потенциальная угроза безопасности, дублирование кода - т.е. мне нужно дублировать все контроллеры, модели, представления и т.д., которые имеют дело с ордерами.

б) Создайте отдельное приложение Rails на веб-сервере, которое будет подключаться к другой БД из нашего внутреннего приложения.

  • +++ Плюсы: Меньше угроз безопасности.
  • --- Минусы: Дополнительные усилия для синхронизации веб-БД и внутренней БД (или с использованием веб-сервиса, такого как REST-API), дополнительный код для обработки истощения запасов и создания # заказа, дублирование кода - т.е. мне нужно дублировать все контроллеры, модели, представления и т. д., которые имеют дело с заказами.

c) Предоставление внутреннего приложения в Интернете

  • +++ Плюсы: все проблемы выше устранены. Это намного "СУХОЙ" метод.
  • --- Минусы: Гораздо больше проблем с безопасностью. Более сложные системы входа в систему — одна для Интернета и одна для внутренних пользователей с использованием LDAP.

Итак, есть мысли? Кто-нибудь имел подобную проблему для решения? Пожалуйста, имейте в виду, что наша компания имеет ограниченные ресурсы, а именно один разработчик, который занимается этим. Так что это должно быть одно из тех «правильных» и «умных» решений, а не решений типа «бросать на это деньги/людей/ресурсы».

Спасибо.


ruby-on-rails web system-design erp intranet
person konung    schedule 01.12.2009    source источник

Ответы (5)


arrow_upward
1
arrow_downward

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

http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html

http://api.rubyonrails.org/classes/ActiveResource/Base.html

Изменить - исправлена ​​ссылка и добавлена ​​ссылка API

person Mike    schedule 01.12.2009
comment
Просто хотел поблагодарить всех, сообщить, что в итоге я выбрал это решение. Спасибо - person konung; 24.03.2010

arrow_upward
1
arrow_downward

Я бы пошел на а. Вы должны иметь возможность создавать контроллеры, чтобы их можно было использовать повторно.

Внутренние пользователи с такой же вероятностью дублируют данные, как и внешние пользователи.

person dr.    schedule 01.12.2009
comment
Меня больше всего беспокоит то, что мне нужно поддерживать 2 копии одного и того же кода. Конечно, мы используем SCM (mercurial), и я должен написать правильные модульные тесты, которые должны упростить обслуживание, но это просто рельсы программиста внутри меня съеживается при мысли о том, чтобы не писать СУХОЙ код :-) - person konung; 01.12.2009

arrow_upward
1
arrow_downward

Вполне вероятно, что общедоступный пользовательский интерфейс и внутренний пользовательский интерфейс для персонала должны будут отличаться. Данные должны быть непротиворечивыми, поэтому я бы приложил немало усилий, чтобы убедиться, что существует ровно одна окончательная база данных. Итак: одна база данных, два пользовательских интерфейса?

Иметь «сервисный» слой, который могут использовать оба пользовательских интерфейса. Если бы это была Java, я был бы уверен, что услуги будут оказаны быстро. Интересно, насколько это просто в Ruby/Rails.

Наилучшим результатом будет то, что ваш существующий пользовательский интерфейс Customer Java можно будет адаптировать для использования сервисного слоя Rails.

person djna    schedule 01.12.2009
comment
Rails в значительной степени дает вам rest-api бесплатно. Извините, если я неясно выразился, но мы пытаемся перенести все имеющиеся у нас разные приложения (java, dbase, vb, php) в одну базу кода в ruby ​​и rails. Но из вашего предложения звучит так, как будто вы голосуете за вариант №3? - person konung; 01.12.2009
comment
Ваш вариант № 3 — иметь одно внутреннее веб-приложение и выставлять его? Нет, это не то, что я имею в виду. В концепции у меня есть три компонента. 1) сервисный уровень, 2) внутренний пользовательский интерфейс и 3). внешний интерфейс. 2 и 3 используют 1. Являются ли компоненты одним приложением, состоящим из трех модулей, или тремя отдельно развернутыми приложениями, это деталь реализации, но я подозреваю, что у вас, по крайней мере, будут отдельные URI для внутренних и внешних пользователей. - person djna; 01.12.2009

arrow_upward
1
arrow_downward

Предполагая, что вы доверяете своим программистам, чтобы они случайно не открыли что-то не в том месте, мне кажется, что «правильным» решением будет одно приложение, но два разных набора контроллеров и представлений, один для внутреннего использования, а другой для публичного использования. Это даст вам идею djna об одной базе данных, двух пользовательских интерфейсах.

Как вы сказали, наличие двух отдельных баз данных приведет к большому количеству дублирования, а также к проблеме репликации.

Для меня нет смысла иметь два совершенно разных приложения, использующих одну и ту же базу данных; часть ActiveRecord приложения Rails является абстракцией базы данных в коде Ruby, поэтому наличие двух абстракций для одной базы данных кажется немного неправильным.

Вы также можете иметь общие бизнес-правила в своих моделях, чтобы избежать дублирования кода в двух версиях сайта.

Если вы не полностью доверяете своим программистам, то подход Майка с ActiveResource довольно хорош — с ним будет намного сложнее случайно раскрыть что-то (хотя ActiveResource намного менее гибок и многофункционален, чем ActiveRecord).

person DanSingerman    schedule 01.12.2009

arrow_upward
1
arrow_downward

Какую версию Rails вы используете? Поскольку включена версия 2.3 Rails Engines, это позволяет совместно использовать общий код (модели/представления/контроллеры) в плагине Rails.

См. краткое введение в Railscast.

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

person nathanvda    schedule 02.12.2009
comment
На самом деле я думал об использовании движков, которые касаются повторного использования кода, однако вторая часть моего вопроса/проблемы связана с безопасностью. Если я настрою систему с движками - она ​​должна будет находиться на одном сервере - поэтому, если я помещу ее в DMZ для внешнего доступа - тогда мне придется столкнуться с головной болью управления доступом к внутренним системам, которые находятся на внутренней стороне брандмауэра. - person konung; 05.12.2009
comment
Код, который вы определяете в плагине, является общим. Однако вы можете отменить это определение, если оно находится в стандартных папках Rails. Так, например: в плагине/общем коде аутентификация осуществляется через вашу собственную базу данных пользователей/паролей, но во внутреннем приложении вы перезаписываете эту модель подключением к LDAP. Как только пользователь аутентифицирован, получает свои роли, поведение остальной части приложения остается прежним. Аналогично: доступ к DMZ находится в общем коде, но только ваше внутреннее приложение будет иметь доступ к внутренней базе данных. - person nathanvda; 05.12.2009
comment
А с двигателями нет необходимости размещать оба приложения на одном сервере. Общий код находится в плагине, папке внутри вашего rails-приложения (vendor/plugins). Просто убедитесь, что ваш плагин находится внутри собственного git-репозитория (для этого я использую подмодули git). Таким образом, я удостоверяюсь, что код плагина идентичен во всех моих приложениях, и любые функции, которые необходимо отменить, я делаю в приложении хостинга rails. Это ясно? Я надеюсь, что это помогает. Я не уверен, что это соответствует вашим потребностям (или я правильно их понимаю). - person nathanvda; 05.12.2009