Configuring SAP SMTP service | SAP Blogs

Описание типовых бизнес-сценариев

Система ЭА на базе стандартной технологии Archivelink охватывает собой все типы бумажных документов, подлежащих учету в связи с проведением по ним хозяйственных операций. По направлению движения все документы можно разделить на два типа:

1. Входящие документы (из внешних организаций, других информационных систем);
2. Исходящие (источником происхождения является SAP ERP).

Входящие документы, в свою очередь, подразделяются на три типовых сценария:

1. Входящие с предварительной регистрацией (документ входит в систему ЭА в момент совершения транзакции, электронный документ SAP уже существует; впоследствии может быть ассоциирован с другими существующими транзакциями).
2. Входящие без предварительной регистрации (документ помещается в ЭА до совершения транзакции, он является основанием для создания одного или нескольких электронных документов SAP).
3. Входящие документы без привязки к объектам SAP (категория документов, для которых сложно установить связь с транзакциями по причине их большого количества или полного отсутствия).

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

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

Для тех, кто любит смотреть скринкамы, есть ссылочка на ЮТуб, описывающая один из типовых проектов по внедрению электронного архива для пользователей SAP:

В этом ролике можно посмотреть, на каком примерно оборудовании можно сделать подобный проект. Дальнейшие, более конкретные вопросы, можно в личку.

Введение

Забегая вперёд, если вы не горите желанием набивать стандартные шишки, вот список вопросов, которые вы должны прояснить для себя в самом начале проекта:

• Scope проекта (Системы, пользователи – в каком порядке внедряем, где приоритет и что можно отбросить если что-то пойдёт не так, какие пользователи должны получить доступ и т.д.)
• Основные отделы, затронутые проектом (Даже если проект по ним проходит «по касательной», всё равно важно, чтобы все были в курсе заранее)
• Ваши полномочия (Здесь не сильно можно разбежаться – в европейской компании всё строится на согласии и добровольном желании помочь. Если отдел скажет, что у них нет ресурсов, то надавить и «заставить» практически невозможно. Но можно позвать стороннего консультанта для помощи, например)
• Сроки (Для всего проекта в целом и для конкретных частей)
• Процедуры согласования (Бюрократические регламенты — в большой компании это далеко не последний вопрос)
• Возможные сложности (Все. Возможные. Сложности.)

У нас состав участников проекта менялся несколько раз: сначала это был только отдел авторизации в SAP и отдел администраторов (Basic Components). Затем к ним присоединились отдел занимающийся авторизацией в Windows (Active Directory, AD) и отдел внедрения обновлений (Packaging), затем отдел баз данных и отдел мобильных приложений, и т.д.

Для технической стороны дела был приглашён внешний консультант, а Project Manager (ПМ) стала я, как человек занимающийся авторизациями в SAP (поэтому деталей по авторизациям в SAP в этой статье будет больше, чем других).

Важное уточнение: весь доступ, который мы даём в SAP, кастомизирован. Мы не пользуемся стандартными ролями, которые предлагает система, а создаём новые, под отдел, под позиции, под функции. На сегодняшний день у нас нет синхронизации между пользователями SAP и Windows AD.

: поддержка электронной подписи по гост р 34.10-2021 в продуктах компании sap ag

Open the port for SMTP

Transaction: RZ10

In case this was not done before, import the profiles

Select the right profile (here: instance profile) and the Extended maintenance option.

To receive emails on an SMTP port, ICM needs to be configured to

1. Open the port and to
2. Use protocol SMTP

Add an entry for SMTP in the instance profile. Here, the port used is 25000.

Save changes to instance profile.

Then save and activate the changes.

Warning message informs that a ICM restart is needed to activate the changes.

Looking in the profile file on the server:

ICM profile file is changed, change is persisted in the file but ICM does not pick up the new configuration automatically. A restart of ICM is needed.

Transaction: SMICM

The Restart option didn’t work for me, a hard exit with a start activated the change. But I am not Basis person.

Confirm the restart of ICM.

Check the SMTP service details. They have to match the new configuration.

Verifying the ICM parameters using SAP MMC.

1 Scope Люди

Люди в нашей компании пользуются SAPом через приложение на личном компьютере (тонкий клиент — SAP Logon GUI), но не только. Как считать пользователей, попадающих под раздачу?

2 Scope Systems

В нашей компании в SAPе используются шесть активных landscapes (ECC, BI, SRM, Netweaver, PI, Solution manager), не считая песочниц. У каждой из них свои DEV, ACC, PRD — т.е. фактически это 6*3 = 18 систем.

Гласным голосованием было решено взять только первые четыре landscapes. PI и SM используются узким кругом администраторов и требуют обновления самой системы (по крайней мере обновления SAP_BASIS component до версии 740). Иначе транзакция sncwizard не поддерживается, а вручную это делать слишком хлопотно ради 10-20 человек.

Компоненты

Люди, интересующиеся тех деталями, найдут на сайте SAP пошаговую инструкцию, так же как и различные доступные способы (мы выбрали SSO based on Kerberos, но это не всегда очевидный вариант).

С очень упрощенной точки зрения (моей), SSO это надстройка в SAP, позволяющая вам заходить в систему, используя свою учётную запись Windows. Вы включаете компьютер, вводите пароль, и для того чтобы зайти в SAP вам достаточно двойного клика.

Чтобы магия сработала нужно 5 составляющих:

1 Изменение параметров системы (instances SAP)

В системе SAP (ECC, BI, SRM, Netweaver) нужно активировать параметр snc/enable =1. Это делается через sncwizard и включает подготовку, перезагрузку системы и окончательные шаги активации.

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

На производстве всегда сложно перезапускать PRD, работа идёт круглосуточно. А в транспортной компании это вдвойне сложнее: транспорт двигается с пяти утра и до часу ночи, даже по выходным. Любые сложности с PRD влияют не только на сотрудников компании, но на весь город и десятки тысяч людей.

Другими словами — нужно минимизировать время, когда система недоступна и по возможности совместить с другими обновлениями. При этом нельзя недооценивать бюрократию: рестарт это заранее согласованные по регламенту даты, время, продолжительность (если с первого раза параметры не сохранятся) и уведомление бизнеса.

У нас было четыре системы SAP PRD: ECC, Netweaver, SRM, BI – для перезагрузки

ECC — самая важная, на неё завязаны все данные реального времени и основной транспорт: автобусы, трамваи.

Данные системы Netweaver (аварии, мобильные приложения), как и системы ECC используются даже в 3 часа ночи — если трамваи не ходят, то ходят ремонтные бригады.

Система SRM — в основном используется для закупок и была доступна в любой день после 18:00.

С BI сложность в том, что на выходных в систему идут потоки загрузки данных из ECC, кроме того, иногда отчёты из BI, используются высшим менеджментом вне рабочих часов.

В совокупности на перезагрузки всех PRD ушло 2 недели.P.S. Рестарту каждой из систем PRD предшествовали рестарты всех DEV и ACC, которые проще в согласовании, но также требуют планирования.

2 Windows Active Directory (AD)

В Active Directory требуется создание специального технического пользователя (SAP Kerberos). Этот пользователь будет связываться с Windows чтобы получить копию входного «тикета» для SAP. Достаточно одного такого сервисного пользователя AD для всех систем SAP.

Эта часть была целиком сделана нашим внешним консультантом и командой Active Directory, включала в себя несколько итераций по уточнению параметров и настройке спец.библиотеки, но для меня в большей степени осталась «чёрным ящиком».

3 Установка на компьютер пользователя программы SAP Secure Login Client (SLC)

Эта программа сама по себе ничего не делает. Она нужна, чтобы хранить тикет от AD, подтверждающий вашего пользователя при входе в сессию Windows, и при необходимости предоставлять этот тикет в SAP для авторизации. SLC можно установить всем пользователям сразу в начале проекта — без остальных компонентов SSO она всё равно работать не будет.

4 Привязка пользователя SAP к его пользователю AD

Как уже было сказано, в нашей компании нет единого управления пользователями, доступ в разных системах получают от разных команд. При этом login пользователя в SAP отличается от имени пользователя в Windows, например пользователь #45011 в AD это Иван Иванов или ИВАНОВИ. Именно эту связку и надо заполнить в SNC (через транзакцию SU01, поле SNC, p:CN=ADname@domain).

В нашей компании нет SAP Identity Management. Поэтому надо было решить две задачи: создание новых пользователей и обновление параметров существующих.

5 Модификация файла SAP logon.ini

Технически это дело 1 минуты. Надо лишь отметить в свойствах файла, что доступно подключение через SNC.

Сложность в том, что этот файлик находится локально на PC пользователя и надо поменять его у двух тысяч пользователей.

Фактически для нас финальное внедрение было моментом распределения нового файла sap.logon.ini среди пользователей, а не изменение параметров PRD. Потому что даже если первые четыре составляющие уже сделаны, а последняя пятая нет, то магия не случится.

С последним пунктом вышел небольшой казус. Я отчиталась перед руководством, что у нас 2000 пользователей, у кого будет установлено обновление, а когда пришло время внедрять, мне прислали статус, где их было 3500. Стало не по себе. Всё потому, что я со своей стороны видела только активных пользователей SAP, а в действительности обновление было отправлено на все персональные ноутбуки, которых в компании гораздо больше. Слава богу никаких багов с технической стороны не возникло.

Configure SMTP service

Transaction: SICF

Save the changes and activate the service.

Тестирование

Как тестировать SSO? Либо он работает, либо нет. Наш разработчик фыркал и говорил, что тестировать ничего не нужно, и как только всё заработает в «песочнице», нужно отсылать в продакшн. Конечно. Nobody will say he writes code with bugs.

Проверять надо:

SSO это не программа, её сложно внедрять последовательно DEV — ACC — PRD. Но тем не менее первичное тестирование необходимо, чтобы уловить всё, что потенциально может пойти не так. Тестирование в данном случае это распределение нового SAP logon.ini, когда все компоненты уже запущены. Мы тестировали DEV и ACC с разработчиками и новый SAP logon.ini c PRD c выборкой бизнес пользователей.

Что нашли:

SNC это дыра в безопасности

Как быть с модификацией поля SNC?Дело в том, что изменив поле SNC у другого пользователя (в SU01) на своё, вы можете подключиться под чужим аккаунтом, даже не меняя пароля. Система вас просто спросит какого пользователя выбрать, вашего или чужого. При этом, если вы это сделаете, завтра никто ничего не заметит, потому что пароль остался неизменным.

Командная работа

За время проекта я столкнулась со всеми сложностями командной работы и открыла для себя много базовых истин:

• Времени много не бывает. Запас времени — это лучшее, что может предусмотреть ПМ.
• Должен быть базовый план проекта, но пересматривать его нужно каждую неделю, оставляя большой запас для гибкости. Где-то мы двигались быстрее, где-то топтались на месте.
• Взрослые дяди в ИТ отделе иногда по поведению не отличаются от девчонок в бухгалтерии: отказываются работать с друг с другом, просто потому что человек им не нравится. И требуется лишний раз урегулировать вопросы субординации.
• Часто отделы тормозят согласование проекта, потому что не понятно на чьей ответственности лежит внедрение и на чей бюджет ложатся дополнительные часы работы. Важно дать менеджерам всё обговорить напрямую.
• То и дело возникают непредвиденные ситуации. Лучшее, что может быть, это своевременная коммуникация, письмо, звонок, смс всем задействованным людям.
• Нет ничего лучше, чем личная встреча. Вопросы решаются в разы быстрее, чем при обсуждении по почте. С другой стороны все личные договоренности должны тут же сопровождаться последующим письмом (чтобы закрепить и не забыть)
• ПМ в ИТ проекте может только доверять людям. На деле вы понятия не имеете сколько реально по времени будет занимать то или иное действие: например, создание пользователя в AD для Kerberos,10 минут или три дня? И нет никакой возможности проверить реально ли стопорилось тестирование или кто-то валял дурака. Остаётся только доверять.

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

Информация для бизнеса

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

Надо признаться, что с коммуникацией всё что могло, пошло не так.

Во-первых, мы объявили пользователям об SSO на корпоративном сайте, а не письмом. Как часто вы читаете корпоративный сайт? Многие просто ничего не заметили до тех пор пока их SAP внезапно не перестал запрашивать пароль.

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

В-третьих, техподдержка написала мне в день Go Live, что они не поддерживают изменения, если документация им пришла меньше чем за неделю (я отправила документацию за 2 дня), и что в случае звонков мы будем выкручиваться сами. Хорошо что технических ошибок не было.

Трудности перевода или последний fuck-up

Проект запустился и уже вовсю шёл 5-ый день эры SSO в нашем SAP, когда мы обнаружили слона, которого никто не заметил.

В компании присутствует два языка: голландский и французский. Априори, благо компания расположена в Брюсселе — у всех стоит французский. Но тем не менее многие сотрудники подключаются через голландский или английский. В общей сложности из 2-х тысяч активных пользователей, почти 500 человек это голландско-говорящие. Раньше они сами всякий раз меняли язык в окошке подключения.

Теперь у всех по дефолту оказался французский. Причём если бы мы оставили галочку “use a default language SAP logon” пустой — никаких вопросов не возникло бы, каждый бы подключался с тем языком, какой у него отмечен в параметрах (SU01, вкладка Defaults). После внедрения посыпались звонки с просьбой «сменить пользователю SAP».

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

Решили проблему отправкой инструкцией о смене языка всем нидерландо-говорящим пользователям дабы предовратить их новые звонки в техподдержку.

Appliance tdi: hana для интернет-магазина

Интернет-магазин Mall.cz, входящий в состав Mall Group, был основан 2000 году. Имеет филиалы в Чехии, Словакии, Польше, Венгрии, Словении, Хорватии и Румынии. Это крупнейший интернет-магазин в стране, продающий до 75 тысяч товаров в день, его выручка по итогам 2021 года составила порядка 280 миллионов евро.

Обновление инфраструктуры ЦОД требовалось в связи с миграцией на SAP HANA. Оцениваемый сайзинг составлял 2×6 ТБ для среды prod и 6 ТБ для сред test/dev. При этом требовалось решение с аварийным восстановлением для продуктивной среды SAP HANA в active-active кластере.

На момент объявления тендера у заказчика имелась система под SAP на базе стандартных стоечных и блейд-серверов. Два ЦОДа, располагавшиеся на расстоянии примерно в 10 км друг от друга, были укомплектованы различными СХД – IBM SVC, HP и Dell. Ключевые системы работали в режиме аварийного восстановления.

Сначала заказчик запросил сертифицированное решение в режиме Appliance для SAP HANA для всех систем (среды Production и test/dev) с ростом до 12 ТБ. Но из-за ограничений бюджета стали рассматривать другие варианты – например, большее количество CPU с модулями ОЗУ меньшего объема (модули по 64 ГБ вместо модулей по 128 ГБ). Кроме того, для оптимизации цены рассматривалось совместное СХД для сред Production и test/dev.

Сошлись на 4 CPU и 6 ТБ RAM для среды Production, с возможностью роста. Для сред test/dev в режиме TDI решили обойтись менее дорогостоящими CPU — получилось 8 CPU и 6 ТБ RAM. Из-за большего количества функций, запрашиваемого заказчиком, — репликация, бэкап, совместные среды Production и test/dev на второй площадке — вместо внутренних дисков задействовали СХД DellEMC Unity в конфигурации full-flash.

Итоговая конфигурация для среды Prod состояла из сервера BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) и с 6 ТБ ОЗУ. СХД — Unity 450F 10x 3.84 ТБ. В целях disaster recovery для среды Prod использовали BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.

10 ГГц, 165 Вт) с 6 ТБ ОЗУ. Для среды test/dev взяли сервер BullSequana S800 с Intel Xeon P8153 (16 ядер, 2.00 ГГц, 125 Вт) и 6 ТБ ОЗУ плюс СХД Unity 450F 15x 3.84 ТБ. В качестве кворума, серверов приложений (VxRail Solution) и решения для бэкапа (DataDomain) наши специалисты установили и настроили серверы DellEMC.

Оборудование готово к будущему апгрейду. Заказчик ожидает рост сайзинга HANA в 2021 году, и ему останется только установить в стойки новые модули.

Appliance tdi: hana для металлургов

ГМК «Норильский никель» — один из крупнейших производителей никеля и палладия — решил обновить свою аппаратную платформу SAP HANA для обеспечения работы критически важных бизнес-приложений и проектов. Требовалось расширение существующего ландшафта в части вычислительных мощностей. Одним из главных условий, выдвинутых заказчиком, стала высокая доступность платформы – несмотря на аппаратные ограничения.

Для продуктивных сред мы использовали сервер Bullion S8 и СХД в режиме SAP HANA Appliance. Для HA и test/dev платформу развернули в режиме TDI. Использовали один сервер Bull Bullion S8, два Bull Bullion S6 и гибридную СХД. Такая комбинация позволила существенно увеличить скорость работы приложений ландшафта SAP, увеличить объем вычислительных мощностей и ресурсов хранения данных и минимизировать операционные расходы. Немаловажно, что у клиента осталась возможность масштабирования до 16 CPU.

Appliance: hana для крупного интегратора в сфере туризма

На этот раз нашим клиентом стал крупный поставщик ИТ-услуг, занимающийся разработкой  технологических решений для туристических компаний. Заказчик запустил амбициозный проект SAP HANA для внедрения новой биллинговой системы. Требовалось решение в режиме Appliance с 8 ТБ ОЗУ для сред Production и PreProd. В соответствии с рекомендациями SAP, заказчик выбрал вариант с вертикальным масштабированием.

Ключевой задачей стало внедрение аппаратной инфраструктуры, основанной на сертифицированных в режиме Appliance устройствах для SAP HANA. Приоритетными критериями являлись эффективность затрат, высокая производительность, возможность масштабирования и высокая доступность данных.

Мы предложили и реализовали решение, сертифицированное SAP, включающее в себя два сервера Bullion S16 – для сред Prod и PreProd. Оборудование работает на процессорах Intel Xeon E7-v4 8890 (24 ядра, 2.20 ГГц, 165 Вт) и оснащается 16 ТБ ОЗУ. Для BW и сред Dev/Test установили девять серверов Bullion S4 (22 ядра, 2.20 ГГц, 150 Вт) по 4 ТБ ОЗУ. В качестве СХД использовалась гибридная EMC Unity.

Такое решение обеспечивает поддержку масштабирования для всех элементов устройства – например, до 16 сокетов с CPU Intel Xeon E7-v4. Администрирование в этой конфигурации упрощено – в частности, для переконфигурирования или разбиения сервера на партиции.

Configuration of smtp in sap

The steps are pretty simple. All are to be executed in the SAP system. I used the NPL Gateway Demo system for this.

Configure the smtp server and outbound and inbound flow

1. SMTP server

Transaction: SCOT

Set the default domain

Sap hana appliance

Appliance – преднастроенное решение, включающее сервер, СХД и пакет ПО для внедрения «под ключ», с централизованной службой поддержки и оговоренным уровнем производительности. Здесь HANA поставляется в виде предварительно настроенного аппаратного и программного обеспечения, полностью интегрированного и сертифицированного.

Сертификация SAP определяет гарантированный уровень производительности, а также модель CPU, объем RAM и СХД. После сертификации изменить конфигурацию без потери гарантии нельзя. Для масштабирования платформы HANA SAP предлагает три варианта.

• Scale-Up BWoH/DM/SoH – вертикальное масштабирование, которое подходит для единых систем (один SID). Рост устройств Appliance происходит по 256/384 ГБ, начиная с версии SAP HANA SPS 11. Это соотношение показывает максимальный объем, поддерживаемый одним CPU, и является общим для всего списка сертифицированных Appliance-устройств. Appliance BWoH/DM/SoH с вертикальным масштабированием оптимально подходит для приложений BW on HANA (BWoH), Data Mart (DM) и приложений SAP Suite on HANA (SoH).
• Scale-Up SoH — это облегченный вариант предыдущей модели, с меньшим количеством ограничений по объему ОЗУ. Это все еще вертикально-масштабируемый сервер, но максимальный объем ОЗУ на 2 процессора составляет уже 1536 ГБ (до версии SPS11) и 3 ТБ (SPS12 ). Подходит только для SoH.
• Scale-Out – это вариант с горизонтальным масштабированием, системой, поддерживающей многосерверные конфигурации. Горизонтальное масштабирование оптимально подходит для BW и – с некоторыми ограничениями – для SoH.

В серверах BullSequana S и Bullion S вертикальное масштабирование является основным, так как имеет меньше операционных ограничений и требует меньше администрирования. Для режима Appliance есть большая линейка разных устройств.

Решения BullSequana S для SAP HANA в режиме Appliance
*Optional E7-8890/94v4
Решения Bullion S для SAP HANA в режиме Appliance

Все решения Bull в режиме Appliance с версии SAP HANA SPS 12 сертифицированы. Оборудование устанавливается в стандартную 19-дюймовую стойку 42U, с двумя источниками питания — внутренними PDU. Сертификацию SAP имеют серверы:

СХД соединяется с сервером напрямую через порты FC, так что коммутаторы SAN здесь не нужны. Они могут пригодиться для доступа к системам, подключенным к LAN или SAN.

Вот пример конфигурации СХД EMC Unity 450F в нашем сетапе:

Appliance — надежный вариант развертывания, но у него есть большой недостаток:

мало свободы в конфигурировании железа

. Кроме того, такой вариант может потребовать изменений в процессах работы ИТ-подразделения.

Sap hana tdi

Альтернативой Appliance является режим TDI (Tailored Data center Integration), в котором можно выбирать конкретных производителей и компоненты инфраструктуры в зависимости от пожеланий заказчика – с учетом выполняемых задач и рабочей нагрузки. Например, SAN может быть повторно использован в ЦОД, при этом некоторые диски отводятся под установку HANA.

По сравнению с Appliance, в режиме TDI пользователю дается гораздо большая свобода в выполнении требований. Это значительно упрощает интеграцию HANA в ЦОД — можно выстроить собственную кастомизированную инфраструктуру. Например, варьировать тип и количество процессоров в зависимости от нагрузки.

Для расчета мощностей рекомендуется использовать SAP Quick Sizer — простой инструмент, выдающий требования к ЦП и памяти для разных рабочих нагрузок в SAP HANA. Затем для планирования IT-ландшафта можно обратиться в SAP Active Global Support. После этого аппаратный партнер SAP HANA преобразует результаты расчетов в разные возможные конфигурации системы — как на топовом, так и на более простом железе. В режиме TDI для серверов

допустимо использовать CPU Intel E7, включая Intel Broadwell E7 и Skylake-SP (Platinum, Gold, Silver с 8 и более ядрами на процессор), а также IBM Power8

/9.

Серверы поставляются без СХД, коммутаторов и стоек, но требования к аппаратной части остаются такими же, как в режиме Appliance — те же сингл-ноды, решения с вертикальным или горизонтальным масштабированием. SAP требует, чтобы использовались только сертифицированные серверы, СХД и коммутаторы, но это не страшно — у большинства производителей практически все оборудование сертифицировано.

Проверка производительности должна проводиться при помощи тестов HWCCT (Hardware Configuration Check Tool), которые позволяют проверить соблюдение определенных KPI SAP. И есть требование, не связанное с железом: HANA, ОС и гипервизор (опционально) должны быть инсталлированы специалистами с сертификацией SAP. Только системы, где соблюдаются все перечисленные правила, могут получать поддержку SAP, связанную с производительностью.

Линейка серверов BullSequana S в режиме TDI аналогична линейке в режиме Appliance, но без СХД, коммутаторов и стойки. К ним можно устанавливать любые СХД из списка сертифицированных SAP — VNX, XtremIO, NetApp и другие. Например, если VNX5400 соответствует требованиям к производительности SAP HANA, можно подключить СХД Dell EMC Unity 450F как часть конфигурации TDI. При необходимости инсталлируются адаптеры FC (1 или 10 Гбит/с), а также Ethernet-свитчи.

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

Sap single sign on (sso) 3.0 configuration for sap abap application server using snc kerberos. | sap blogs

Виртуализация sap hana

Одним из главных ограничений SAP HANA является поддержка только одной системы — одного инстанса с уникальным SID сервера. Для более эффективного использования аппаратного обеспечения или уменьшения количества серверов в ЦОД можно использовать виртуализацию.

Таким образом другие ландшафты могут сосуществовать на одном сервере с системами, имеющими меньшие требования (непродуктивные системы). Для резервного HA/DR-сервера виртуализация может повысить скорость переключения между продуктивными и непродуктивными виртуальными машинами.

SAP HANA включает поддержку гипервизора VMWare ESX. Это означает, что разные системы SAP HANA – инсталляции SAP HANA с различными номерами SID – могут сосуществовать на едином хосте (общем физическом сервере) в разных виртуальных машинах. Каждая виртуальная машина должна работать в поддерживаемой ОС.

Для продуктивных сред виртуализация SAP HANA имеет серьезные ограничения:

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

Входящие документы без предварительной регистрации

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

Изначально ШК этих документов несет в себе информацию о типе документа и маршруте его движения. Печать наклейки со ШК производится из разработанной транзакции Z*. При выборе из справочника значения полей «Обрабатывающее подразделение» и «Тип документа» зависят друг от друга, т.е. из списка можно выбрать только те документы, с которыми работают конкретные подразделения.

Сценарий работы при этом можно описать схемой:

Входящие документы без привязки к стандартным объектам SAP – это особый подвид документов, которым нельзя поставить в соответствие стандартный бизнес-объект (например, справки), либо которым соответствует массив проводок (например, отчеты). Вследствие чего для данного подвида документов можно создать искусственный Z-объект, не содержащий проводок. На этот бизнес-объект можно просто вешать ссылки на массив заархивированных документов с атрибутами.

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

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

Входящие документы с предварительной регистрацией — это документы, попадающие в систему ЭА в момент, когда электронный документ SAP уже существует. Иными словами, документ крепится к уже совершенной транзакции. Проводку выполняет тот же сотрудник, который выполнил приём документов.

Формирование идентификационной наклейки с ШК происходит из соответствующей бизнес-транзакции. Для работы с такими документами в каждую транзакцию может быть, например, внедрена новая функциональность: кнопка «Регистрация приложений».

Сценарий работы при этом можно описать схемой:

Исходящие документы

Исходящие документ – это документы, формируемые системой SAP. Сценарий работы с исходящими документами предназначен для архивирования подписанных контрагентом экземпляров исходящих документов.

Функциональность формирования ШК интегрирована в бизнес-транзакцию, из которой выполняется печать. Необходимость использовать наклейку со ШК отсутствует (ШК печатается одновременно с документом).

Приглашаем на sap форум

В этом посте мы разобрали развертывание SAP HANA разными способами, постарались осветить преимущества и недостатки доступных вариантов. Если у вас появились какие-то вопросы по внедрению SAP HANA, мы будем рады ответить на них в комментариях.

Всех, кто заинтересовался решениями Bull и возможностями их внедрения под SAP HANA, приглашаем на крупнейшее SAP-событие года: 17 апреля в Москве пройдет SAP Форум 2021. Ждем вас у нашего стенда в зоне IoT: расскажем много интересного, а также разыграем множество призов.

До встречи на форуме!

Развертываем sap hana в режимах appliance и tdi

Теперь перейдем к практике и расскажем о том, как реализовать SAP HANA в режимах Appliance и TDI. Используем для этого наши платформы SAP HANA на основе серверов BullSequana S и Bullion S, которые сертифицированы SAP для работы в этих режимах.

Небольшая справка о продуктах. BullSequana S на базе Intel Xeon Scalable включает в себя различные модели, до 32 CPU в одном сервере. Сервер построен по модульной конструкции, обеспечивающей масштабируемость до 32 CPU и такого же количества графических процессоров.

Оперативная память – от 64 ГБ до 48 ТБ. Среди особенностей BullSequana S – поддержка корпоративного ИИ для улучшенной производительности, ускорение аналитики данных, усовершенствование вычислений в памяти, модернизация с помощью виртуализации и облачных технологий.

Bullion S поставляются с CPU семейства Intel Xeon E7 v4 Family. Максимальное количество процессоров — 16. ОЗУ масштабируется со 128 ГБ до 24 ТБ. Большое количество функций RAS обеспечивает высокий уровень доступности для критически важных инфраструктур наподобие SAP HANA.

Способы маркирования документов

На исходящих документах (формируемых SAP) изображение штрихкода печатается одновременно с печатью документа на лазерном принтере.

На входящие документы, независимо от сценария, штрихкод помещается при помощи наклейки, например такой:

… впрочем, мы же хотели здесь говорить про сам Archivelink. Продолжим в технической плоскости.

Техническая схема взаимодействия компонент archivelink

Описание схемы взаимодействия компонент решения SAP Document Access by OpenText на основе стандартной технологии Archivelink в сценарии массового сканирования документов со ШК:

Топологии sap hana

Перейдем к развертыванию SAP HANA. Здесь определены две топологии.

Требования sap к железу

К аппаратному обеспечению для HANA у SAP есть обязательные требования. Они касаются продуктивных сред — для non-prod достаточно минимальных характеристик. Итак, вот требования для продуктивных сред:

Итоги и выводы

В целом внедрить SSO — это просто, когда вы это уже сделали хотя бы один раз в жизни. Говорят, что это вопрос 1-2 недель работы, но никак не 3-х месяцев.

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

Многие вещи про SSO были, возможно, уже давно известны, как минимум, гуглу. Например про запрос сервера к AD, или поле SNC. Но есть такая вещь, как вечная нехватка времени. Как специалист вы обязаны гуглить, а как менеджер проекта (особенно если вы не можете разобраться в первые полчаса, и у вас нет профильного образования) — вы должны найти самый короткий путь к решению.

Как правило, самым коротким путём оказывается спросить, причём спросить устно. 

Сухой остаток: