Разработчик ПО для бизнеса SAP объявил об уходе из России и прекращении поддержки локальных продуктов Статьи редакции
Компания уже перестала продавать свои продукты в стране.
- Немецкая компания объявила, что перестает работать с российскими клиентами и поддерживать локальные продукты. Она объяснила, что «скоординированные санкции» — это лучший способ закончить «военную операцию» на Украине.
- Пользователи облачных сервисов, которые не находятся под санкциями, смогут удалить свои данные, выгрузить их или перенести в центр обработки данных за пределами России. В последнем случае SAP не будет продлевать договор после истечения подписки.
- Компания также прекращает поддержку и обслуживание локальных продуктов в России. Сейчас она рассматривает несколько вариантов, как это сделать, чтобы выполнить все свои обязательства. Клиенты смогут по-прежнему пользоваться продуктами.
- SAP — один из крупнейших в мире поставщиков приложений для бизнеса. В России среди клиентов компании — «Сбербанк», «Газпром» и другие компании, в том числе малого и среднего бизнеса, писало РБК. В начале марта 2022 года компания «поставила на паузу все продажи, а также прекратила поддержку клиентов, включенных в санкционные списки США и ЕС», говорил близкий к SAP источник.
0
показов
18K
открытий
1
репост
Все бабки слиты
Перейдут на 1С: такая же xpeнь, только с худшим дизайном.
Де-факто если большое предприятие и внедрен SAP для перехода потребуются колоссальные затраты. Плюс почти весь штат придётся уволить, так как системы абсолютно разные. По факту это выкинуть все что есть и строить заново. Плюс многие отмечают, что 1С просто неспособно заменить крупные ИС-структуры.
это возможности заработать, а то воплей слишком много что заказчиков в сфере ИТ в стране не останется как западные компании уйдут :)
Плюс многие отмечают, что 1С просто неспособно заменить крупные ИС-структуры.ну тут зеркальные мнения, 1С-франчи с вами вряд ли согласятся :) а я вот скорее да чем нет.
1. Нужно чтобы были эти деньги, которых хватит на все перестроить. Если внедрение длится годами или десятилетиями, то предполагаемый переход сейчас должен пройти резко, но ни одна из сторон процесса к этому не готова.
2. Мое мнение немного ангажированно т.к. я работаю с АХ, но это та информация, которую мне сообщали коллеги по отрасли. Что 1С плохо подходит для высоконагруженных или сложных систем. Может это не так, но из того что я видел: 1С разворачивают на куче серверов, на которых работает по несколько пользователей чтобы обеспечить стабильную работу клиентов при большом количестве пользователей.
2. Достаточно понимать, как 1с работает с данными, чтобы разобраться, почему она плохо подходит для замены высоконагруженных систем.
САП иначе как-то работает?
У них сейчас вроде как своя СУБД с полной поддержкой ACID. До этого был Oracle. А как 1С реализует транзакционность? Средствами платформы или сервера БД?
И 1С использует реляционные СУБД с поддержкой ACID. Так почему SAP работает иначе?
А в том-то и дело, что 1C сама пытается реализовать ACID. В то время, как этим должен заниматься сервер БД. Дайте проф, если ошибаюсь.
Вы правы в том, что 1С частично реализует принцип ACID на своей стороне. Но только это наоборот плюс, а не минус.
Если отдать изоляцию транзакций полностью на откуп СУБД, то придется устанавливать высокий уровень изоляции транзакций (например, Serializable или Repeatable Read), что приведет к проблемам с параллельностью работы пользователей, т.к. в большинстве случаев будут устанавливаться избыточные блокировки.
1С использует довольно высокий уровень изоляции на СУБД (Read Committed Snapshot), а доп.блокировки ресурсов, (чтобы избежать неповторяемое чтение, потерянное обновление и др. артефакты), устанавливает уже разработчик в зависимости от бизнес-логики.
В результате берем лучшее от СУБД + а теми ресурсами, на которые СУБД ставил бы избыточные блокировки, управляем самостоятельно.
Вот и получается, что есть одна система изоляции на стороне сервера БД, и поверх нее, на стороне ORM, реализуется еще один контроллер изоляции, что конечно не бесплатно.
Кстати, установка уровня изоляции на стороне сервера БД не является чем-то сложным. Более того, это возможно настраивать для сеанса и даже отдельной процедуры (что-то вроде SET TRANSACTION ISOLATION LEVEL SERIALIZABLE);
По большому счету, "высокий уровень" изоляции оправдан для достаточно сложных транзакций, по мере выполнения которых происходят обращения к другим ресурсам системы, которые могли измениться с начала выполнения транзакции. Так ли уж часто это встречается в 1С?
Да, классический пример - списание товара со склада, конкуренция за остатки.
В общем вы аргументируете только тем, что 1С используют 2 системы управления изоляцией, поэтому она такая медленная. Еще раз повторюсь, что дело не в этом.
Путь с использованием только изоляций/блокировок СУБД 1С уже проходила, они избыточны. Использование такого режима на текущий день признается моветоном.
Пример: я хочу считать остатки товаров из таблицы, чтобы понять могу я продать товар или нет.
Serializable заблокирует в таком случае все считанные данные + 1 строку, причем если оптимизатор запроса выбрал скан - то будут заблокированы записи и по другим складам.
Если я выберу более низкий уровень изоляций (например Read Commited Snapshot) - блокировки не получу, но получу грязное/неповторяемое чтение, фантомы и тд - т.е. данные будут неконсистентны.
Поэтому я выбираю вариант Read Commited Snapshot + на стороне 1С ставлю блокировку по конкретному складу.
Скажите, я правильно понял, что списание условных остатков в 1с происходит так:
1) платформа блокирует для всех пользователей запросы к изменяемым таблицам (вероятно, ставит в очередь)
2) проверяет, возможно ли списание (не станет ли остаток отрицательным)
3) продолжая удерживать блокировку, вносит изменения.
4) вероятно, еще раз проверяет консистентность регистров
5) снимает блокировку
То есть таблица блокируется целиком? Это блокировка ведь только на запись?