Коллеги, приветствую! Есть вопрос по использованию календарей. Поделитесь опытом, пожалуйста! Есть вот такой типовой кейс из жизни, например, тех поддержки территориально распределённой организации. Сотрудник из Новосибирска подаёт заявку на первую линию, которая располагается в Перми, а обрабатывает её вторая линия в Москве. Срок выполнения заявки (которая зарегистрирована пермским сотрудником первой линии) зафиксирован в SLA для московской рабочей группы по московскому времени (например, они поддерживают общекорпоративную информационную систему в режиме 5х8). Время подачи по Новосибу 9 утра. Максимальная длительность решения по SLA - 4 часа, т.е. срок исполнения 13.00 по Москве, по Новосибу - соответственно 17.00, а по Перми 15.00. Календарь, по которому нужно считать крайний срок, определён в SLA. Соответственно, вроде бы логичен процесс, у которого на очередном шаге определяется SLA, а по нему - и календарь, и длительность, и крайний срок. Но в ELMA расчёт крайнего срока по календарю с учётом часового пояса выполняется только в контексте пользователя (либо текущего, либо определённого в контексте процесса), который (календарь) определяется с помощью метода GetProductionSchedule. В ELMA нет функции с расчётом длительности просто по произвольному календарю. Более того, в календаре не указывается часовой пояс - он указывается только у пользователя. Можно, конечно, завести фиктивных пользователей, которых использовать как календари, но это какое-то известное место, а не решение. Прошу помощи. 1. Как такую задачу решают опытные товарищи? 2. Как видят крайний срок разные сотрудники в разных часовых поясах? По идее каждый должен видеть своё локальное время (13.00 по Москве, 17.00 - по Новосибу, 15.00 - по Перми). Это так?
По поводу рабочих календарей и часового пояса, действительно в ELMA нет связи между календарем и часовым поясом, т.к. календарь определяет праздничные и выходные дни и рабочее время в них, а в рамках нашей страны производственный календарь как правило один на всю страну, а часовых поясов может быть много. Такова логика системы. По поводу SLA: ELMA устанавливается на каком-то сервере, в определенном часовом поясе и использует системное время с этого сервера при работе со временем. Чаще всего это время совпадает с головным отделением компании и на него ориентируются при предоставлении географически-распределенных услуг, то есть это является базовым часовым поясом компании. Исходя из этого времени делаются все расчеты в ELMA. Поэтому все, что вам нужно это взять производственный календарь, взять текущее время и добавить к нему время решение проблемы, которое у вас декларируется по SLA. ELMA вернет вам срок, с учетом этого производственного календаря. Примеры вычисления дат с учетом календаря можно посмотреть тут: https://www.elma-bpm.ru/KB/article-5999.html и тут: https://www.elma-bpm.ru/KB/article-5494.html Для вашего примера, я бы предложил такое решение: В Новосибирске создается задача в 9.00, системное время - 5.00 (допустим Московское), SLA - 4 часа с учетом рабочего графика с 9.00 до 18.00 будет выглядеть, как 13.00 по системному времени (5 утра - нерабочее время, поэтому отсчет начнется только с 9 утра). По поводу времени у пользователей, все они видят время с поправкой на свой часовой пояс, то есть по одной и той же задаче пользователь из Новосибирска увидит срок выполнения: 17.00, а в Москве будет виден срок 13.00, хотя срок у задачи задается только в одном времени. Для расчета срока, часовые пояса пользователей вам не понадобятся.
Алексей, спасибо Вам большое за ответ! С отображением часовых поясов понятно. А вот с расчётом - нет. В указанных статьях время считается по одному и тому же производственному календарю, PublicAPI.Services.ProductionCalendar. Но моя задача требует гибкого выбора календаря. Продолжая заданный пример, допустим, есть две московские группы - одна работает 5x8 и тогда для неё крайний срок 9+4=13 часов, а другая работает 24х7 и тогда для неё крайний срок 5+4=9. И тогда использованием PublicAPI.Services.ProductionCalendar будет давать ошибку либо для первой, либо для второй группы. Т.е. в общем случае одна и та же задача может выполняться по разным календарям. При этом, если совсем уж корректно, этот календарь может определяется не рабочей группой, и не только SLA, а любой совокупностью параметров. И как тут обойтись одним календарём PublicAPI.Services.ProductionCalendar, не понимаю? Нужно именно так, как я написал: календарь определяется контекстно - в зависимости от SLA или любой другой совокупности параметров - на предыдущих шагах процесса, а когда нужно - считается крайний срок или длительность между датами по этому календарю. Имеющийся метод ProductionCalendarService.GetProductionSchedule имеет входящий параметр User, других вариантов не нашёл. ((