Добрый день! Сам о SAP не знаю пока практически ничего, потому строго не судите.
Вопрос мой состоит в следующем:
В отделении копании в другой стране внедрен sap (точно по модулям не скажу, да, думаю, это и не имеет особого значени в моем вопросе).
Живет это все там на SLES или RH (точно не помню), база живет на Oracle (так же какой-то никсовой платформе - SLES или RH).
теперь планируется внедрение в другом отделении компании.
Но! Система разработки будет только в одном подразделении.
И теперь сама суть вопроса. Возможно внедрение системы в новом отделении компании не на никсах, а на Windows серверах? Повлияет ли это на разработку? ибо она будет вестись на платформах, описанных выше (SLES, RH). Возможна ли в таком случае миграция данных, перенос настроек и всего остального барахла?
Надеюсь вы поймете, что я имею в виду! Smile
Всем заранее спасибо за ответы Smile

SAP платформонезависимая ERP и сервера приложений масштабируются и на никсы и на виндуза и на аих, от БД тоже не зависит - можно и на оракле и на на мс скуле и на дб2.

То есть я правильно понимаю, что:
Приложение (или как это в сапе называется), разработанное на sap системе, развернутой на другой платформе (ну то есть на системе разработки) может быть без проблем продеплоено в систему тестирования, которая живет на другой платформе (на винде, скажем)?

Просто нужно принять решение, на чем будет жить sap. Но, так как разработчики буду лупашить все на системах, которые живут на никсах, не возникнет ли проблем потом с переносом разработки в продуктив? Либо придется разворачиваться точно на тех же платформах, что и у разработчиков...

Не, проблем возникнуть не должно. Особенно, если придерживаться стандартного стиля САП.
А вы точно хотите поднимать свою отдельную систему? САП вполне нормально работает в больших организациях. И если необдуманно плодить системы - могут возникнуть проблемы с переносом данных из разряда "ой, а нам нужно перенести БП. И Материалы. А еще настройки синхронизировать". А это сам по себе немалый проект.

Да, без локальной системы тестирования и продуктива не обойтись. ни один провайдер в России, к сожалению, не способен обеспечить в нормальном качестве бесперебойную работу каналов в режиме 24\7 (не пытайтесь доказать обратное, проверено работой со всеми ведущими провайдерами в России:) )... А вот разработка будет централизованная. И очень хочется иметь локальные системы на винде.
Но очень опасаюсь проблем с переносом изменений из разработки в тестовый контур и в продуктив.

Если хотите собственноочно убедится - поставьте локально систему и попробуйте перенести туда все что хочется.
SAP использует в основном 2 стека: ABAP и Java. Вторая изначально - платформонезависимая. Одноко практически вся ERP написана на первом - ABAP. Разработки на этом языке компилируются в байткод (а не в машинный код), а затем выполняются ядром системы. Ядра есть под кучу платформ.

По поводу обрывов связи: разумеется они есть. Каждая компания считает, что все сервисы должны работать идеально и простой совершенно недопустим, но на практике ИТ системы большинства крупных организаций падали на некоторое время . Ничего страшного, бывает. У нас на московских серверах работают филиалы по всей России. Иногда работают и из разных стран и ничего.

При правильном подходе проблем быть не должно. Наблюдал когда сервера были на разных ОСях (AIX / Win) и проблем это не вызывало.

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

Собственноочно убедиться, к сожалению, нет возможности, ибо оборудование еще не приехало, ставить все это добро некуда. А решение надо принимать уже сейчас.

Обновления и корректировки (патчи) могут относиться либо к самому стеку (ABAP или Java) - в таком случае они также не зависят от платформы. Либо к ядру - оно обновляется отдельно для каждой платфомы. Однако, во-первых обновления ядра выходят редко, а во-вторых устанавливаются они не сразу же после выхода - самые разуиные сначала ждут, пока оно все устаканится и все остальные проверят работоспособность Т.е. на момент установки - у вас будет ядро под все платформы.

А кто у вас будет внедрять?

Andrew_Nice, я совсем не базисник, но вот что хочу сказать:
1. Архитектура, когда разработки ведутся централизовано в одной системе, но продуктивные системы разные - для SAP противоестественна (в отличие от 1С, например).
2. Выбор такой архитектуры на единственном основании опасения проблем с каналами связи выглядит противоестественно вдвойне. Я лично знаю примеры крупнейших компании России из нефтегаза и ритейла, у которых сервера SAP в Швейцарии, а пользуются им во в разных концах нашей необъятной родины.

LKU, а чего в ней противоестественного? Если система разработки реально одна? Не вижу никаких проблем. Это накладывает определенные требования к квалификации разработчиков и постановщиков. Не более того.

прикольно:) если чо, то ... всё-таки Лукашенко относительно Баумгертнера выходит прав:) (ну это который в уралкалии заправляет).

Бывает и так, но с некоторыми недостатками.
К примеру, на одном из проектов была одна продуктивная система в которой была реализована финансовая часть (шаблон решения) и несколько продуктивных систем.
То есть из одной системы - запросы переносились массово в другие системы.
С точки зрения разработчика - был строгий регламент наименования объектов, чтобы объекты одного проекта не перетирали объекты - другого.
Есть сложности в реализации user-exit (только один объект) и BAdI с однократным внедреним. Все это успешно решается созданием многократных Z-BAdI в тиражируемом шаблоне.

Ну скажем так, я отталкиваюсь от своего понимания, которое конечно ограничено моим личным опытом.
Можно ли так сделать с технической точки зрения (настроить транспортную систему) - верю что можно.
Можно ли так сделать организационно - тоже можно, хотя трудозатраты на внедрение и поддержку возрастут.
Есть ли в такой схеме экономический смысл для клиента - мне кажется, нет.