Как стартует бизнес процесс 1с

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

Люди и процессы

• Средства разработки (Конфигуратор)
• Веб-клиент
• Серверная инфраструктура и отказоустойчивый кластер
• и т.д.

С другой стороны, в практиках, которые направлены «вовнутрь», команды достаточно автономны. Например, инспекции кода сейчас применяются во всех командах (и существуют общие правила, определяющие обязательность прохождения ревью), но были внедрены в разное время и процесс построен по разным правилам.
То же самое касается организации процесса — кто-то практикует варианты Agile, кто-то использует другие стили ведения проекта. Канонического SCRUM, кажется, нет нигде — специфика коробочного продукта накладывает свои ограничения. Например, замечательная практика демонстрации оказывается неприменимой в неизменном виде.

Бизнес-процесс в 1С — твой друг и помощник!

Другие практики, например, роль Product Owner, имеют у нас свои аналоги. В качестве Product Owner по своему направлению обычно выступает руководитель группы. Помимо технического лидерства в команде, одной из самых главных его задач является определение дальнейших направлений развития. Процессы выработки стратегии и тактики развития платформы – это сложная и интересная тема, которой мы посвятим отдельную статью.

Работа над задачами

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

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

• Анализ проблемы и вариантов решения
• Описание выбранного решения
• Описания технических деталей реализации

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

Уроки и рецепты

• Ценность проектного документа, как любой документации, не всегда бывает очевидна. Для нас она в следующем:

Бизнес-процесс «Привлечение клиента» в 1С

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

Обеспечение качества

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

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

Тесты

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

Unit-тесты

На C++ мы пишем unit-тесты. Как уже упоминалось в предыдущей статье, мы используем модифицированные варианты Google Test и Google Mock. Например, типичный тест, проверяющий экранирование символа амперсанда («) при записи JSON, может выглядеть так:

TEST(TestEscaping, EscapeAmpersand) < // Arrange IFileExPtr file = create_instance(SCOM_CLSIDOF(TempFile)); JSONWriterSettings settings; settings.escapeAmpersand = true; settings.newLineSymbols = eJSONNewLineSymbolsNone; JSONStreamWriter::Ptr writer = create_json_writer(file, // Act writer->writeStartObject(); writer->writePropertyName(L»_); writer->writeStringValue(L»_); writer->writeEndObject(); writer->close(); // Assert std::wstring result = helpers::read_from_file(file); std::wstring expected = std::wstring(L»»); ASSERT_EQ(expected, result); >

Интеграционные тесты

Следующий уровень тестирования — интеграционные тесты, написанные на языке «1С:Предприятие». Именно они образуют основную часть наших тестов. Типичный набор тестов представляет собой отдельную информационную базу, хранящуюся в *.dt файле. Инфраструктура тестов загружает эту базу и вызывает в ней заранее известный метод, который вызывает уже отдельные тесты, написанные разработчиками, и форматирует их результаты так, чтобы их могла интерпретировать инфраструктура CI (Continuous Integration).

json»); ИмяЭталона = «эталон_Массив_Простой»; Значение = Общие.ПолучитьПростойМассив(); ЗаписьJSON = ПолучитьОткрытуюЗаписьJSON(ИмяФайла); ЗаписатьJSON(ЗаписьJSON, Значение); ЗаписьJSON.Закрыть(); Общие.СравнитьФайлСЭталоном(ИмяФайла, ИмяЭталона); КонецПроцедуры

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

Наша система CI сама выполняет эти тесты под различные версии ОС и СУБД, включая 32- и 64-разрядные Windows и Linux, а из СУБД — MS SQL Server, Oracle, PostgreSQL, IBM DB2, а также нашу собственную файловую базу.

Пользовательские тестовые системы

Третий и самый громоздкий вид тестов — это т.н. «Пользовательские тестовые системы». Они применяются тогда, когда проверяемый сценарий выходит за пределы одной базы на 1С, например, при тестировании взаимодействия с внешними системами через веб-сервисы. Для каждой группы тестов выделяется одна или несколько виртуальных машин, на каждую из которых устанавливается специальная программа-агент. В остальном разработчик теста имеет полную свободу, ограниченную только требованием выдавать результат в виде файла в формате Google Test, который может быть прочитан CI.

Например, для тестирования клиента SOAP веб-сервисов используется сервис, написанный на C#, а для проверки различных возможностей конфигуратора — объёмный фреймворк тестов, написанных на питоне.
Оборотной стороной такой свободы является необходимость ручной настройки тестов под каждую ОС, управление парком виртуальных машин и прочие накладные расходы. Поэтому, по мере развития наших интеграционных тестов (описанных в предыдущем разделе), мы планируем ограничивать использование пользовательских тестовых систем.

Упомянутые выше тесты пишут сами разработчики платформы, на С++ или создавая небольшие конфигурации (прикладные решения), заточенные под тестирование конкретного функционала. Это является необходимым условием отсутствия ошибок, но не достаточным, особенно в такой системе как платформа 1С: Предприятие, где большая часть возможностей не являются прикладными (используемыми пользователем напрямую), а служат основой для построения прикладных программ. Поэтому существует ещё один эшелон тестирования: автоматизированные и ручные сценарные тесты на реальных прикладных решениях. К этой же группе можно отнести и нагрузочные тесты. Это интересная и большая тема, про которую мы планируем отдельную статью.

При этом все виды тестов выполняются на CI. В качестве сервера непрерывной интеграции используется Jenkins. Вот как он выглядит на момент написания статьи:

Для каждой конфигурации сборки(Windows x86 и x64, Linux x86 и x64) заведены свои задачи по сборке, которые запускаются параллельно на разных машинах. Сборка одной конфигурации занимает длительное время — даже на мощном оборудовании компиляция и линковка больших объёмов C++ представляет непростую задачу. Кроме того, создание пакетов под Linux (deb и rpm), как оказалось, занимает сопоставимое с компиляцией время.
Поэтому в течение дня работает «укороченная сборка», которая проверяет компилируемость под Windows x86 и Linux x64 и выполняет минимальный набор тестов, а каждую ночь работает регулярная сборка, собирающая все конфигурации и прогоняющая все тесты. Каждая собранная и проверенная ночная сборка помечается тэгом — так, чтобы разработчик, создавая ветку для задачи или вливая изменения из основной ветки, был уверен, что работает с компилирующейся и работоспособной копией. Сейчас мы работаем над тем, чтобы регулярная сборка запускалась чаще и включала больше тестов. Конечная цель этой работы — обнаружение ошибки тестами (если её можно обнаружить тестами) в течение не более двух часов после коммита, чтобы найденная ошибка была исправлена до конца рабочего дня. Такое время реакции резко повышает эффективность: во-первых, самому разработчику не нужно восстанавливать контекст, с которым он работал во время привнесения ошибки, во-вторых, меньше вероятность, что ошибка заблокирует чью-нибудь ещё работу.

Статический и динамический анализ

• CppCheck
• PVS-Studio
• Встроенный в Microsoft Visual Studio

• обращений к неинициализированной памяти
• обращений к освобождённой памяти
• выходов за границы массива и т.д.

Организационные меры обеспечения качества

Помимо автоматических проверок, выполняемых машинами, мы стараемся встраивать обеспечение качества в ежедневный процесс разработки.
Наиболее широко применяемая практика для этого — peer code review. Как показывает наш опыт, постоянные инспекции кода не столько отлавливают конкретные ошибки (хотя и это периодически происходит), сколько предотвращают их появление за счёт обеспечения более читаемого и хорошо организованного кода, т.е. обеспечивают качество «в долгую».
Другие цели преследует ручная проверка работы друг друга программистами внутри группы — оказывается, даже поверхностное тестирование не погруженным в задачу человеком помогает выявить ошибки на раннем этапе, ещё до того, как задача влита в ствол.

Eat your own dogfood

Но самым эффективным из всех организационных мер оказывается подход, который в Microsoft называется «eat your own dogfood», при котором разработчики продукта оказываются первыми его пользователями. В нашем случае «продуктом» оказывается наш таск-трекер (упомянутая выше «База задач»), с которой разработчик работает в течение дня. Каждый день эта конфигурация переводится на последнюю собранную на CI версию платформы, и все недочеты и недостатки сразу сказываются на их авторах.
Хочется подчеркнуть, что «База задач» — серьёзная информационная система, хранящая информацию о десятках тысяч задач и ошибок, а число пользователей превышает сотню. Это не сравнимо с самыми крупными внедрениями 1С: Предприятия, но вполне сопоставимо с фирмой среднего размера. Конечно, не все механизмы можно проверить таким способом (например, никак не задействована бухгалтерская подсистема), но для того, чтобы увеличить покрытие проверяемого функционала, есть договоренность, что разные группы разработчиков используют разные способы подключения, например, кто-то использует Web-клиент, кто-то тонкий клиент на Windows, а кто-то на Linux. Кроме того, используется несколько экземпляров сервера базы задач, работающие в разных конфигурациях (разные версии, разные ОС и т.д.), которые синхронизируются между собой, используя входящие в платформу механизмы.
Помимо Базы задач есть и другие «подопытные» базы, но менее функциональные и менее нагруженные.

Выученные уроки

• В таком большом и массово используемом продукте дешевле написать тест, чем не написать. Если в функциональности есть ошибка и она будет пропущена — затраты конечных пользователей, партнеров, службы поддержки и даже одного отдела разработки, связанные с воспроизведением, исправлением и последующей проверкой ошибки будут куда больше.
• Даже если написание автоматических тестов затруднительно, можно попросить разработчика подготовить формализованное описание ручных тестов. Прочитав его, можно будет найти лакуны в том, как разработчик проверял своё детище, а значит, и потенциальные ошибки.
• Создание инфраструктуры для CI и тестов — дело затратное и по финансам, и по времени. Особенно, если приходится это делать для уже зрелого проекта. Поэтому начинайте как можно раньше!

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

• 1С
• erp системы
• программирование
• тестирование по
• 1с:предприятие

• Блог компании 1С
• Разработка веб-сайтов
• Тестирование IT-систем

Источник: habr.com

Бизнес-процесс производства

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

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

Использование механизма бизнес-процессов наиболее эффективно после их адаптации под особенности работы вашего предприятия.

Для начала использования бизнес-процесса в производстве изделий заполните данные на закладке «Основное» бизнес-процесса.

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

Запуск бизнес-процесса производится кнопкой «Старт бизнес-процесса»

После запуска бизнес-процесса начинается проход по его маршруту с автоматическим созданием задач соответствующим пользователям.

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

Форма задачи пользователя содержит название задачи, текст задания, и срок исполнения.

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

Важно! Маршрут бизнес-процесса может быть изменен под требования каждого конкретного предприятия с учетом специфики прохождения задач на предприятии.

Источник: nashe-proizvodstvo.ru

Каталог решений — Простейший пример создания бизнес-процессов

Простой пример создания бизнес-процессов в несколько шагов. Может пригодиться при первом знакомстве с ними или для решении задач экзамена 1С:Специалист по платформе.

Начало

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

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

В случае же, если Вы только начинаете изучение бизнес-процессов, то добро пожаловать! Далее будет очень много картинок!

Что необходимо

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

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

Шаг за шагом

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

Шаг №1: Добавляем справочники

На первом этапе добавим в конфигурацию необходимые справочники с соответствующими предопределенными элементами.

Заполнение предопределенных элементов мы осуществили в соответствии со значениями адресации задач на карте маршрута (см. выше).

Шаг 2: Сохраняем текущего пользователя

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

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

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

Шаг №3: Создаем задачи

На третьем шаге создадим объект конфигурации «Задача», чтобы в дальнейшем бизнес-процесс адресовал задачи установленным пользователям. Для этого добавим объект конфигурации в ветке «Задачи» и дадим ему такое же имя.

Прежде чем настраивать свойства добавленного объекта, нам необходимо создать регистр адресации задач, по содержимому которого система будет определять конечного исполнителя для задачи (пользователя). Для этого добавим регистр сведений «РолиИсполнителейЗадач» с тремя измерениями. Тип измерений понятен по их именам.

Теперь необходимо в свойстве объекта задач выполнить следующие настройки:Описанные настройки на вкладке «Адресация» влияют на поведение системы при присвоении исполнителя задачам, создаваемым бизнес-процессом. Немного подробнее:

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

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

На этом настройка объекта «Задачи» завершена. Теперь мы можем перейти непосредственно к созданию бизнес-процесса.

Шаг №4: Создаем бизнес-процесс

Четвертый шаг — он важный самый. Теперь мы начинаем работать непосредственно с бизнес-процессом. Создаем новый объект конфигурации «БизнесПроцесс» в ветке «Бизнес-процессы».

В нем мы добавили реквизит «ОплатаИзКассы» с типом «Булево», чтобы перед стартом бизнес-процесса указать способ выплаты (через банк или кассу). Значение именно этого реквизита будет указывать на какую точку действия необходимо перейти на карте маршрута.

В свойствах бизнес-процесса на вкладке «Основные» укажем для свойства «Задачи» созданный нами ранее объект задач.

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

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

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