Начать транзакцию 1с 8. Создание пользовательских транзакций для ведения объектов OM. Создание новой транзакции для собственного объекта организационного менеджмента

В прошлый раз мы рассмотрели простейший способ средствами встроенного языка 1С. На практике транзакции гораздо чаще используются совместно с конструкцией . Это позволяет в случае ошибки продолжить выполнение кода, а также выдать адекватное сообщение об ошибке пользователю и записать информацию в журнал регистрации или в файл логов для последующего анализа администратором системы.

Если мы обратимся к технической документации или к диску ИТС, то увидим, что фирма 1С рекомендует следующий способ организации транзакции в попытке

Собственно каких-то особых пояснений код не требует. Если в процессе попытки выполнения транзакционного кода возникает ошибка, мы сразу проваливаемся в блок исключение , т.е. до метода ЗафиксироватьТранзакцию() мы просто не доходим. Ну а в исключении соответственно отменяем транзакцию и если это необходимо выводим сообщение об ошибке и записываем информацию в журнал регистрации. Фиксировать ошибки в журнале регистрации крайне желательно, особенно для тех операций, которые выполняются без участия пользователя (например, регламентные задания). Это позволит в дальнейшем проанализировать ошибку. Вместо записи в журнал регистрации можно организовать отправку сообщений администратору по электронной почте.

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

А теперь поместим транзакцию в блок Попытка Исключение . Скорее всего ошибки могут возникнуть только в момент записи в справочник или в регистр сведений, поэтому предварительную подготовку вынесем за пределы транзакции.

Как НЕ НАДО делать

У тех кто только начинает работать с транзакциями зачастую возникает желание сделать вот таким образом

НачатьТранзакцию() ; Попытка НачатьТранзакцию() ; //Блок операций ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; КонецПопытки ; Попытка НачатьТранзакцию() ; //Блок операций ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; КонецПопытки ; ЗафиксироватьТранзакцию() ;

Или в цикле

НачатьТранзакцию() ; Для каждого Данные Из МассивДанных Цикл Попытка НачатьТранзакцию() ; Данные. Записать() ; ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; КонецПопытки ; КонецЦикла ; ЗафиксироватьТранзакцию() ;

На первый взгляд мы сделали все в соответствии с рекомендациями фирмы 1С. Но дело в том, что платформа 1С не поддерживает вложенные транзакции. То есть чисто технически так писать можно. Но при этом все вложенные транзакции не образуют новые, а относятся к той же самой транзакции верхнего уровня. Таким образом, если в одной из вложенных транзакций произойдет ошибка, следующую вложенную транзакцию нельзя будет зафиксировать. Система выдаст сообщение вида: «В данной транзакции уже происходили ошибки!» . Продемонстрируем это на примере. Допустим мы решили записать два товара, каждый в своей транзакции. И сделаем эти транзакции вложенными в третью. Далее искусственно вызовем ошибку в первой транзакции с помощью метода ВызватьИсключение :

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

{ВнешняяОбработка.ТранзакцииВПопытке.Форма.Форма.Форма(20)}: Ошибка записи товара. {ВнешняяОбработка.ТранзакцииВПопытке.Форма.Форма.Форма(40)}: Ошибка при вызове метода контекста (Записать): В данной транзакции уже происходили ошибки!

Таким образом, организация вложенных транзакций в 1С абсолютно бессмысленна.

Возможные варианты

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

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

Независимо от выбранного варианта работы (файловый или клиент-серверный) система «1С:Предприятие» обеспечивает работу с информацией, хранящейся в базе данных, с использованием механизма транзакций.

Транзакция - это неделимая с точки зрения воздействия на базу данных последовательность операций манипулирования данными. Она выполняется по принципу «все или ничего» и переводит базу данных из одного целостного состояния в другое целостное состояние. Если по каким-либо причинам одно из действий транзакции невыполнимо или произошло какое-либо нарушение работы системы, база данных возвращается в то состояние, которое было до начала транзакции (происходит откат транзакции).

Система «1С:Предприятие» осуществляет неявный вызов транзакций при выполнении любых действий, связанных с модификацией информации, хранящейся в базе данных. Например, все обработчики событий, расположенные в модулях объектов и наборов записей, связанные с модификацией данных базы данных, вызываются в транзакции. В транзакции выполняется также чтение объектов следующих типов: ПланОбменаОбъект, ДокументОбъект, СправочникОбъект, ПланВидовХарактеристикОбъект, ПланВидовРасчетаОбъект, ПланСчетовОбъект, БизнесПроцессОбъект, ЗадачаОбъект, ПоследовательностьНаборЗаписей, РегистрСведенийНаборЗаписей, РегистрНакопленияНаборЗаписей, РегистрБухгалтерииНаборЗаписей, РегистрРасчетаНаборЗаписей, ПерерасчетНаборЗаписей . При этом в режиме управляемых блокировок выполняется установка разделяемой блокировки по значению регистратора для наборов записей и по значениям отбора для набора записей независимого регистра сведений.

Наряду с этим разработчик может использовать работу с транзакциями в явном виде. Для этого используются процедуры глобального контекста НачатьТранзакцию(), ЗафиксироватьТранзакцию() и ОтменитьТранзакцию().

Использование явного вызова транзакций

Метод НачатьТранзакцию() позволяет открыть транзакцию. После этого все изменения информации базы данных, выполняемые последующими операторами, могут быть либо целиком приняты, либо целиком отвергнуты. Для принятия всех выполненных изменений используется метод ЗафиксироватьТранзакцию() . Для того чтобы отменить все изменения, выполнявшиеся в открытой транзакции, используется метод ОтменитьТранзакцию() . Если количество вызовов метода НачатьТранзакцию() превышает количество вызовов методов ЗафиксироватьТранзакцию() или ОтменитьТранзакцию() , то система выполнит неявный вызов метода ОтменитьТранзакцию() в следующих случаях:

● при окончании выполнения встроенного языка (обработчик события, внешнее соединение, automation-сервер);

● при передаче управления с сервера на клиента.

Если количество вызовов методов ЗафиксироватьТранзакцию() или ОтменитьТранзакцию() превышает количество вызовов метода НачатьТранзакцию() , то при выполнении лишнего вызова метода ЗафиксироватьТранзакцию() или ОтменитьТранзакцию() будет порождено исключение. Таким образом, схема работы с транзакцией в общем виде может выглядеть следующим образом:

Попытка

НачатьТранзакцию();

// Последовательность операторов

ЗафиксироватьТранзакцию();

Исключение

ОтменитьТранзакцию();

КонецПопытки;

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

● невосстановимые,

● восстановимые.

Невосстановимые ошибки - это ошибки, при возникновении которых нормальное функционирование системы «1С:Предприятие» может быть нарушено, например, могут быть испорчены данные. При возникновении невосстановимой ошибки выполнение системы «1С:Предприятие» прекращается в любом случае. Если невосстановимая ошибка произошла в процессе выполнения транзакции, то все изменения, сделанные в рамках этой транзакции, отменяются системой.

Восстановимые ошибки - это ошибки, не вызывающие серьезных нарушений в работе системы «1С:Предприятие». В случае возникновения восстановимой ошибки дальнейшая работа системы может быть продолжена. При этом, естественно, сама операция, вызвавшая ошибку, прекращается, и вызывается исключение, которое может быть перехвачено и обработано конструкцией

Попытка … Исключение … КонецПопытки.

Вложенный вызов транзакций

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

НачатьТранзакцию();

НачатьТранзакцию();

ЗафиксироватьТранзакцию();

// Вложенный вызов транзакции

НачатьТранзакцию();

ЗафиксироватьТранзакцию();

ЗафиксироватьТранзакцию();

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

ВНИМАНИЕ! Система «1С:Предприятие» не поддерживает вложенных транзакций. Это означает, что всегда действует только транзакция самого верхнего уровня.

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

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

В общем случае программные объекты, используемые системой «1С:Предприятие», абсолютно «прозрачны» для транзакций базы данных. Иначе говоря, транзакции базы данных могут вызываться при выполнении различных методов программных объектов, однако, например, действия, выполняемые базой данных при откате транзакции, в общем случае никак не влияют на соответствующие программные объекты.

Из этого следует, что при отмене транзакций базы данных разработчик (если в этом есть необходимость) должен самостоятельно обеспечивать адекватное изменение данных соответствующих программных объектов. Это можно выполнять путем повторного чтения всех данных объекта или путем изменения некоторых реквизитов программного объекта.

В этом правиле есть исключения. В силу значительной прикладной специфики программных объектов системы «1С:Предприятие» в некоторых случаях откат изменений, выполненных в базе данных, все же может влиять на значения свойств соответствующих программных объектов. Это происходит в следующих случаях:

● при отмене транзакции признак проведения документа восстанавливает значение, которое было до начала транзакции;

● если объект был создан и записан в транзакции, то при откате транзакции очищается значение ссылки;

● если объект создавался вне транзакции и при записи его в транзакции использовался код/номер, сгенерированный автоматически, то при отмене транзакции код/номер очищается.

Данная статья содержит, в большей мере, теоретические сведения, необходимые для понимания важности транзакций и блокировок 1С:Підприємство и СУБД и это отражается на производительности 1С:Підприємство. В статье популярно описана связь транзакций и блокировок через уровни изоляции и проблемы параллельного доступа.
Данная статья не несет практических советов по решению конкретных проблем, но является основой для понимания следующих статей, в которых описываются шаги по оптимизации и улучшению производительности 1С:Підприємство, связанную с транзакциями и блокировками.

Производительность напрямую связана с ТРАНЗАКЦИЯМИ 1С:Підприємство

«Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded .
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=34, Severity=10, native=1222, line=1»

Если 1С:Підприємство выдает ошибку примерно такого содержания то, Вы имеете дело с проблемами производительности, связанными с блокировками. Решение такого рода проблем не всегда тривиальные и требуют определенных специальных знаний по работе СУБД и 1С:Підприємство, которыми часто не владеют ни программисты 1С:Підприємство, ни системные администраторы. Следующий цикл статей как раз должен заполнить пробел этих знаний.

Транзакции 1С:Підприємство

Транзакция - это неделимая последовательность операций над данными. Она выполняется по принципу «все или ничего» и переводит базу данных
из одного целостного состояния в другое целостное состояние. Если по каким-либо причинам одно из действий транзакции невыполнимо или произошло какое-либо нарушение работы системы, база данных возвращается в то состояние, которое было до начала транзакции (происходит откат транзакции).

К механизму транзакций выдвигается ряд требований (известный под аббревиатурой ACID): Атомарность (Atomicity ), Согласованность (Consistency ), Изолированность (Isolation ), Устойчивость (Durability )

Атомарность (Atomicity ). Это требование заключается в том, что все данные, с которыми работает транзакция, должны быть либо подтверждены (commit ), либо отменены (rollback ). Не должно быть ситуации, когда часть изменений подтверждается, а часть – отменяется.

Для 1С:Підприємство свойства Атомарности транзакций обеспечивают логическую целостность данных. Например при записи документа, его данные шапки записываются в одну физическую таблицу СУБД, а данные табличной части в другую. Запись документа в транзакции дает гарантии что данные в обоих физических таблицах (шапок и табличных частей) будут согласованы (невозможна ситуация записи табличной части без шапки или наоборот).

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

Журнал транзакций (SQL Server)

Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все изменения данных, произведенные в каждой транзакции. Если транзакция по каким-то причинам не завершилась (откатилась или прервалась), то SQL сервер по журналу транзакций отменяет все операции транзакции последовательно в обратном порядке. Это означает, что длительная транзакция на запись, будет долго и отменяться.

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

В зависимости от настроек базы данных (recovery model) журнал транзакций транзакции может обрезаться (удаляются данные старых транзакции) либо автоматически, либо вручную(recovery model=FULL). Иногда системный администратор забывает обрезать журнал и может возникнуть ошибка: "The transaction log for database is full "

Физически журнал транзакций СУБД MS SQL Server находится в файле.LDF (а файл данных - .MDF).

Транзакции в системе «1С:Підприємство»

Система «1С:Підприємство» осуществляет неявный вызов транзакций при выполнении любых действий, связанных с модификацией информации, хранящейся в базе данных. Например, все обработчики событий, расположенные в модулях объектов и наборов записей, связанные с модификацией данных базы данных, вызываются в транзакции.

Пример неявной транзакции: последовательность событий при проведении документа из формы

Практически определить что запись объекта 1С:Підприємство (например документа) происходи тв транзакции можно проведя следующий опыт: Попробовать провести и закрыть (нажать "ОК" в форме документа) новый документ заранее зная что он не проведется (например указав большое количество товара для списания). Так как остатки проверяются на этапе проведения документа, в обработчике "ОбработкаПроведения()", то к этому моменту сам документ уже должен быть записан в базу, так как запись документа происходит ранее между событиями "ПередЗаписью()" и "ПриЗаписи()". Но после появления сообщения об ошибке (отсутствие необходимого количества), Мы обнаружим что документ в базу не записан (останется флаг модифицированности "*" и в списке документ не появиться). Это происходит потому что транзакция после возникновения ошибки отменяется (откатывается "rollback").

Использование явного вызова транзакций

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

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

Проблемы параллельного доступа

При параллельном выполнении транзакций возможны следующие проблемы:
- потерянное обновление (англ. lost update) - при одновременном изменении одного блока данных разными транзакциями, одно из изменений теряется;
- «грязное» чтение (англ. dirty read) - чтение данных, добавленных или изменённых транзакцией, которая впоследствии не подтвердится (откатится);
- неповторяющееся чтение (англ. non-repeatable read) - при повторном чтении в рамках одной транзакции, ранее прочитанные данные оказываются изменёнными;
- фантомное чтение (англ. phantom reads) - одна транзакция в ходе своего выполнения несколько раз выбирает множество строк по одним и тем же критериям. Другая транзакция в интервалах между этими выборками добавляет или удаляет строки, попадающие в критерии выборки первой транзакции, и успешно заканчивается. В результате получится, что одни и те же выборки в первой транзакции дают разные множества строк.

Рассмотрим ситуации, в которых возможно возникновение данных проблем:

Потерянное обновление

«Грязное» чтение

Если предыдущая проблема возникает при записи данных, то «грязное» чтение возможно, когда одна транзакция пытается прочитать данные, с которыми работает другая параллельная транзакция.
Предположим, имеется две транзакции, открытые различными приложениями, в которых выполнены следующие SQL-операторы:

Неповторяющееся чтение

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

В Транзакции2 выбирается значение поля f2, затем в Транзакции1 изменяется значение поля f2. При повторной попытке выбора значения из поля f2 в транзакции 1 будет получен другой результат. Эта ситуация особенно неприемлема, когда данные считываются с целью их частичного изменения и обратной записи в базу данных.

Фантомное чтение

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

В Транзакции2 выполняется SQL-оператор, использующий все значения поля f2. Затем в Транзакции1 выполняется вставка новой строки, приводящая к тому, что повторное выполнение SQL-оператора в транзакции 2 выдаст другой результат. Такая ситуация называется фантомной вставкой и является частным случаем неповторяющегося чтения.

Уровни изоляции транзакций

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

Стандартом Введены следующие четыре уровня изоляции, применение которых предотвращает определенные проблемы параллельного доступа:
- READ_UNCOMMITTED - нефиксированное чтение. Этот уровень изоляции решает проблему "потерянного обновления", но при этом возможно получение разных результатов для одинаковых запросов без учета фиксации транзакции (возможна проблема «грязного чтения»). Это самый низкий уровень изоляции, используемый в СУБД, который обеспечивает максимальную параллельность работы.
- READ_COMMITTED - фиксированное чтение. Это уровень изоляции предотвращает проблему "грязного чтения", но позволяет получать разные результаты для одинаковых запросов в транзакции (сохраняется возможность «неповторяющегося чтения»);
- REPEATABLE_READ - повторяющееся чтение. Это уровень изоляции решает проблему "неповторяющегося чтения". На этом уровне сохраняется возможно выполнение операторов INSERT, приводящих к конфликтной ситуации «фантомная вставка». Этот уровень целесообразно использовать, если на выполняющиеся SQL-операторы не влияет добавление новых строк;
- SERIALIZABLE - последовательное выполнение. Третий уровень. Этот уровень гарантирует предотвращение всех описанных выше проблем параллельного доступа, но соответственно, наблюдается самая низкая степень параллелизма, так как обработка транзакций (с доступом к одним и тем же ресурсам) проводится только последовательно.

Решение проблемы параллельного доступа транзакций и уровни изоляции в виде таблицы можно изобразить так («+» - проблема исключена):

На уровне SQL сервера можно устанавливать уровень изоляции самостоятельно:
для всего сеанса, например директивой
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

для конкретного запроса с помощью конструкции WITH
SELECT Name FROM Contracts WITH SERIALIZABLE

Узнать уровень изоляции, установленный в текущей сессии
select transaction_isolation_level from sys.dm_exec_sessions
where session_id = @@spid

В автоматическом режиме (старый режим, который применялся в 8.0) управления блокировками данных используются уровни изоляции транзакций REPEATABLE_READ и SERIALIZABLE , обеспечиваемые системой управления базами данных. Эти уровни изоляции транзакций обеспечивают согласованное и целостное чтение данных, и от разработчика не требуется каких-либо дополнительных действий по управлению блокировками.

Управляемый режим блокировок (начиная с версии 8.1) позволяет повысить параллельность работы пользователей в клиент-серверном варианте работы за счет использования более низкого уровня изоляции транзакций базы данных (READ_COMMITTED ); этот же уровень изоляции установлен по умолчанию
и в MS SQL сервере. При записи данных в транзакции объекты встроенного языка автоматически блокируют необходимые данные. Но при чтении разработчику требуется управлять блокировками данных в тех случаях, когда бизнес-логика требует согласованного и целостного чтения данных в транзакции.

Для версии 8.3 в управляемом режиме используется уровень изоляции READ_COMMITTED_SNAPSHOT .

Выводы

Транзакции - необходимый механизм СУБД, который активно используется в 1С:Підприємство. Для решения проблем параллельного доступа транзакции в СУБД могут выполняться с различными уровнями изоляции.

Используемый «1С:Підприємство» уровень изоляции READ_COMMITTED решает проблемы «Потерянное обновление» и «Грязное чтение»: измененные данные блокируются до конца транзакции и для чтения и для изменения (накладывается исключительная блокировка).

Уровень изоляции READ_COMMITTED не решает проблемы «Неповторяющееся чтение» и «Фантомное чтение». Чтобы решить эти проблемы необходимо использовать управляемые блокировки «1С:Підприємство», установленные программно.

В 8.3 используется более гибкий уровень изоляции READ_COMMITTED_SNAPSHOT .

В рамках подготовки к сертификации 1С «Эксперт» в преддверии двух очень важных и глобальных тем — блокировок и хотелось бы разобрать то, без чего невозможны вышеназванные понятия, — транзакция СУБД.

Транзакция — логически связанная, неделимая последовательность действий. Транзакция может быть либо выполнена целиком, либо вообще не выполнена. Для фиксации транзакции в СУБД используется метод COMMIT.

Типичный пример транзакции — перевод денежных средств с одного счета на другой:

1. начать транзакцию;
2. прочесть количество денежных средств на счету номер 123;
3. уменьшить баланс счета 123 на 100 рублей;
4. сохранить баланс счёта номер 123;
5. прочесть количество денежных средств на счету номер 321;
6. увеличить баланс на 100 рублей;
7. записать новое количество денежных средств на счете 321;
8. зафиксировать транзакцию.

Получите 267 видеоуроков по 1С бесплатно:

Как мы видим, если транзакция выполнена не полностью, то она не имеет смысла.

Ключевые требования (ACID) к транзакционной СУБД

Одним из наиболее распространённых наборов требований к транзакциям и транзакционным СУБД является набор ACID (Atomicity, Consistency, Isolation, Durability). Это те свойства, которыми должна обладать любая транзакция:

• Атомарность (Atomicity) — никакая транзакция не должна быть зафиксирована частично;
• Согласованность (Consistency) — система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции;
• Изолированность (Isolation) — во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат;
• Надежность (Durability) — в случая сбоя изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу.

Транзакции в 1С

Транзакции в 1С 8.3 и 8.2 создаются как автоматически, так и описываются разработчиками.

С помощью метода ТранзакцияАктивна() можно узнать, активна ли транзакция.

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

2017-10-31

Как создать вариант для транзакции с помощью SHD0 ?

Пояснение к вопросу

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

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

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

Из исходных данных: транзакция, с которой работают пользователи - PA30 . Инфо-тип в данном случае не имеет значения. Конкретно в своем примере, я буду использовать инфо-тип кадрового администрирования.

В качестве примера хорошо подойдет инфо-тип 0002 - "Personal Data"

Задачу по так называемому разграничению полномочий сформулируем следующим образом:

• Поле Mar.Status инфо-типа 0002 "Personal Data" необходимо сделать недоступным для редактирования (то есть только на чтение);
• Поле Valid From Date of Current Marital Status инфо-типа 0002 "Personal Data" необходимо скрыть.

Решение вопроса

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

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

1. Создание новой транзакции

Так как в качестве основной транзакции выступает PA30 , возьмем ее за основу, скопировав в новую. Выполнить это можно через транзакцию SE93

В таблице T588A скопируем существующую запись с кодом транзакции PA30 для новой, и попробуем запустить новую транзакцию еще раз

Транзакция успешно запускается. Переходим к следующему пункту.

2. Создание варианта для новой транзакции

Создаем вариант для новой транзакции, в котором определяем уровень доступа к полям инфо-типа. Напомню, мне необходимо изменить уровень доступа полей "Mar.Status " и "Valid From Date of Current Marital Status» . Выполнять эти действия необходимо в транзакции SHD0 .

В поле Transaction Code укажите наименование новой транзакции (см. пункт #1. Создание новой транзакции)

2.1 Создание варианта для экрана

На закладке "Screen Variants" необходимо создать вариант экрана, используемый для инфо-типа 0002. В этом варианте следует применить нужные правила отображения для полей. Все что нужно знать - это соответствующий пул модулей и номер экрана (для этого, на экране редактирования инфо-типа выберите в меню System -> Status )

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

Вариант экрана создан. Никаких изменений пока не наблюдается.

2.2 Присвоение варианта экрана варианту транзакции

Выполните присвоение созданного варианта экрана варианту транзакции, после чего выполните активацию созданного варианта транзакции

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

Сценарий тестирования очень прост:

• Запустите транзакцию PA30 , выберите табельный номер, откройте на редактирование инфо-тип 0002 и проверьте, что вышеуказанные поля отображаются без изменений

• Запустите транзакцию ZPA30 , и выполните точно такую же последовательность действий

Разница очевидна, а значит и поставленная задача успешно выполнена.