Функция изменения времени с учетом рабочих часов
Постановка задачи
Необходим типовой маршрут, да такой чтобы срок исполнения заданий был динамическим и предварительно уже рассчитанным в блоке сценария. Конкретнее: сотрудники технического отдела согласно внутренним стандартам находятся в жестких рамках решения поступившего вопроса так, например: не более 8 рабочих часов на анализ проблемы и информирование ответственного сотрудника, не более 16 рабочих часов на решение вопроса и так далее. Общее возможное затраченное время на решение не должно превышать более 48 рабочих часов (суммарное время на выполнение всей задачи).
Заметим, что если в свойствах типового маршрута устанавливать Относительный срок, допустим 4 часа, то отсчет данного времени начнется только после завершения работы с предыдущим заданием, а не от старта задачи. А в нашем случае необходимо будет из этих 4 часов вычесть время, затраченное на выполнение предыдущих заданий. (Здесь очень важна коллективная работа и ответственность каждого участника, ведь если один из сотрудников задержит выполнение своего задания к следующему исполнителю задание придет уже просроченным!)
Для вычисления данного вида срока была разработана функция «ChangeTime» изменение времени, подобная функции «ChangeDate».
Функция изменяет время (часы) от заданной даты и саму дату, если количество увеличенных часов более 8 (напомню, подсчет осуществляется только в рабочих часах). Первоначально задается два параметра: Дата, требующая изменения и число часов, на которое требуется изменить время.
Далее в типовом маршруте первым блоком устанавливаем блок «сценарий» и прописываем вычисления на изменение даты и последовательно заносим полученные данные в параметры типового маршрута. И конечно не забываем указать параметры в свойствах блоков «Задание» в поле срок.
Пример:
//определим дату обращения клиента из справочника ТП
DateObr = СпрРекв(КодКомп;Код;"ДатаВремя";;;)
// изменить на 4 часа
Four = ChangeTime (DateObr;4)
ТМУстановитьПараметрЗадачи("Four";Four)
// изменить на 8 часов
Eight = ChangeTime (DateObr;8)
ТМУстановитьПараметрЗадачи("Eight";Eight)
// изменить на 16 часов
Sixteen = ChangeTime (DateObr;16)
ТМУстановитьПараметрЗадачи("Sixteen";Sixteen)
В перспективе, есть возможность предусмотреть изменение не только часов, но и минут и секунд. В нашей задаче пока этого не требовалось.
Ниже предложен один из вариантов реализации функции для версии 4.5.1. и выше
Есть еще недокументированный метод ServiceFactory.GetRelativeDate, который выдает дату-время, сдвинутую вперед на указанное число временных единиц с учетом календаря рабочего времени. Пример использования:
ВремяЧерез30Минут = ServiceFactory.GetRelativeDate(ServerDateTime(); 30 ; dotMinutes)
Спасибо за информацию, к сожалению не нашла описания в справке. Обязательно опробую данный метод!
Да, и вроде как данный метод не работает в разрезе рабочих дней, в отличие от функции.
Сегодня ServiceFactory.GetRelativeDate(ServerDateTime(); 3; dotDays) - показывает 15е число, т.е. выходные учитываются. Если отсчитывать в часах или в минутах, то учитываются рабочие часы. Проверял на DIRECTUM 4.6.1 (но и в других должно быть аналогично, этот метод не менялся уже очень давно). Правда, похоже, этот метод выдает все-таки не Дату-Время, а просто Дату... Т.е. "время через 1 рабочий час", к сожалению, им не получить. Так что функция нужна.
А какие еще есть недокументированные возможности DIRECTUM? А то тоже пришлось писать подобную функцию (правда для директум 4.4), а тут оказывается уже все готовое было :)
Да, лучше создать отдельную тему для этого, если их не мало...
А может в клиете есть еще и Easter Eggs ("пасхальные яйца")?:)
Давайте создадим, пусть директумовцы выкладывают, чтобы велосипед каждый раз не изобретать
Поддерживаю!!
>> Если отсчитывать в часах или в минутах, то учитываются рабочие часы.
И
>> Правда, похоже, этот метод выдает все-таки не Дату-Время, а просто Дату... Т.е. "время через 1 рабочий час", к сожалению, им не получить.
Немного несоответствуют друг другу?
P.S. Метод возвращает именно Дату-Время.
>> Правда, похоже, этот метод выдает все-таки не Дату-Время, а просто Дату... Т.е. "время через 1 рабочий час", к сожалению, им не получить.
Возможно автор стал жертвой типичного недоразумения - если значение типа Дата-Время выводить на экран при помощи функции ShowMessage (она же Окно), то показывается только Дата. Поэтому даже если метод возвращает дату со временем (а это действительно так), то конструкция вида ShowMessage(ServiceFactory.GetRelativeDate(...)) покажет только дату.
Для корректного вывода на экран дат со временем используйте FormatDate...
Да, Дамир. Ты совершенно прав. Я слегка запутался из-за того, что ServerDateTime() в ShowMessage выводила дату со временем, а GetRelativeDate только дату. Сейчас посмотрел справку по ServerDateTime, оказывается там форматирование еще делается, поэтому и отображается.
Вывод - метод реабилитирован.
А метод ServiceFactory.GetRelativeDate(...) учитывает содержимое справочника "Календари рабочего времени" или учитывает только выходные?
Насколько я в нем разобрался, для определения нерабочего времени (в том числе выходных) он пользуется как раз справочником.
Круто! Выкидываю свою самописную функцию в утиль и беру на вооружение этот метод. Вот только бы описание к нему хоть какое-нибудь не помешало :(
Да работает в рамках календаря рабочего времени
Описание метода:
Получить дату, отстоящую от заданной, на заданное количество дней/часов/минут/секунд в соответствии с календарем рабочего времени.
GetRelativeDate – получить значение относительной даты
Синтаксис:
Function GetRelativeDate(
StartDate: TDateTime;
Number: Integer;
NumberType: TDateOffsetType): TDateTime;
Входные параметры:
StartDate – дата, от которой рассчитывается относительная дата;
Number – величина смещения. Должна быть больше или равна 0;
NumberType – тип смещения.
Описание:
Получить дату, отстоящую от заданной, на заданное количество дней/часов/минут/секунд в соответствии с календарем рабочего времени.
Спасибо за информацию. Если не секрет, то откуда описание метода взяли?
isbobj.chm Справочная система по объектной модели.
Что-то никак не могу найти этот файл. Помню, что где-то натыкался на него, а где натыкался не помню :(
Скачал с сайта поддержки "IS Builder 7 7 Объектная модель DIRECTUM.chm", там нет описания данного метода. :(
Да, действительно этот файл - невидимка. Я его нашла в дистрибутиве Directum 4.3 ...\CLIENT\CommonAppData\NPO Computer\IS-Builder\7.5.1\Localization\en\isbobj.chm и больше этот файл нигде не встречался! Мне тоже очень хотелось бы получить полную версию объектной модели!
Ну, дело-то не в файле. Вовсе он не невидимка, это обычная справка по объектной модели. Входит в состав общей справки, вызывающейся по F1. У меня этот файл лежит тут: C:\Users\All Users\NPO Computer\IS-Builder\7.7.0\Localization\ru\ObjModel.chm (это путь для Win7, для остальных путь слегка другой, но тоже в All Users). Только вот описания этого метода там нет. Более того, если получить библиотеку типов sbrte в каком-нибудь просмотрщике этой самой библиотеки (например, в Object Browser VBA), то и там этот метод у IServiveFactory не обнаруживается. Не опубликован он в библиотеке. Но работает. Вот такой секретный.
Согласна, но секретным метод стал, начиная с версии 4.3.1. правильно? а в версии 4.3. он был общедоступным
. Почему же перестали публиковать данный метод?
Это мне не известно.
Попробую выяснить. Может, Дамир что-нибудь скажет, раз он в курсе нашего обсуждения.
Денис, файл isbobj.chm не может лежать по пути ...\ObjModel.chm
>> Более того, если получить библиотеку типов sbrte в каком-нибудь просмотрщике этой самой библиотеки (например, в Object Browser VBA), то и там этот метод у IServiveFactory не обнаруживается. Не опубликован он в библиотеке. Но работает. Вот такой секретный.
Если взять не "какой-нибудь", а нормальный, то метод там будет (и будет помечен скрытым). Скрыли его для "облегчения" интерфейса IServiceFactory.
Может, если его переименовали.
Видимо, зря скрыли. Т.к. ничего взамен не дали... Я уже увидел, где его скрыли... в 7.5.0.
И все же почему перестали публиковать данный метод? и много их таких...
Насколько я помню, методы скрывали по причине их невостребованности. Иными словами, если метод носит сугубо системное значение и/или не используется в стандартной прикладной разработке DIRECTUM и при этом загромождает объектную модель, то его скрывали. Основная цель - упростить объектную модель. При этом любой код, который все-таки использовал этот метод продолжает прекрасно работать (т.е. скрытие метода не приводит к нарушению совместимости).
Не мало. Но скрытых - абсолютное меньшинство :-)
А как получить их список с описанием? :)
На мой запрос в службу поддержки они ответили:
"Метод GetRelativeDate объекта IServiceFactory не подлежит распространению, поэтому в документации он не описан.
Подобную информацию мы не предоставляем."
В принципе правильно ответили. Может тогда кто из разработчиков поделиться информацией по скрытым методам, а то вдруг там есть еще что-нибудь "вкусное"? :)
Смотрите библиотеку типов в Sbrte.exe. Там всё есть
Однако имейте в виду, что если метод скрыт, то его может и не оказаться в следующей версии, или его сигнатура будет изменена, а изменение не описано в документации и т.п.
Список - при помощи любого средства импорта COM Type Library, умеющего игнорировать флаг "Hidden". Например, Delphi.
Описание - только спрашивать у разработчиков.
Спасибо за информацию, но вот это:
сразу отпугнуло использовать скрытые методы :)
Может тогда где-нибудь на форуме обсудить какие методы стоит обратно открыть и чтобы их описание появилось в справочной системе? Мне вот, например, конкретно этот метод очень бы пригодился, но использовать теперь его рискованно :( Тем более выяснилось, что не только мне одному он нужен.
В книге Джоэля Спольски "Лучшие примеры разработки ПО" есть замечательное эссе Эрика Липперта "Сколько работников Microsoft нужно, чтобы сменить лампочку?"
Если найдете - не пожалейте времени, чтобы почитать.
Смысл в том, что в большой компании даже самые незначительные (на первый взгляд) изменения задействуют сотрудников большого числа подразделений и стоят очень дорого. Поэтому простым обсуждением в стиле "А давайте сделаем" действовать не получается.
Хм..так можно далеко зайти и в один прекрасный момент незначительные изменения вдруг станут значительными и тогда необходимо будет задействовать еще больше ресурсов. А книгу обязательно найду, спасибо
Т.е. ты против обсуждения?
Выходит, разработчики платформы скрывают методы по причине их невостребованности прикладными программистами, но данные о востребованности собирать не хотят? 
Вот смотри, что написал Дамир:
Где в этом методе "сугубо системное значение"? Вполне понятная прикладная задача - определить некий срок с учетом рабочего времени. Если те, кто согласовывал это изменение, не учли, что этот метод по смыслу не системный и потенциально может быть востребован, значит обсуждать такие вещи с конечным потребителем (в данном случае - прикладными разработчиками) все-таки нужно.
Присоединяюсь к мнению Дениса :)
Я против обсуждения ради обсуждения. Хотелось бы заранее увидеть свет в конце тоннеля его цель.
Ну ведь очевидно же, что здесь просто ошиблись/перестарались.
Мы сейчас можем здесь обсуждать все, что угодно, но я не вижу, как и в какой конкретно версии что-то будет дорабатываться. Другое дело, если поставить глобально вопрос о доработках объектной модели, скажем, в концепцию DIRECTUM 4.8 - тогда можно будет к этому вопросу подойти системно и устранить множество подобных нелогичностей и непонятностей.
Денис, ты манипулируешь фактами, излагая их не полностью :-) Я писал: "...если метод носит сугубо системное значение и/или не используется в стандартной прикладной разработке DIRECTUM..."
Значит на тот момент метод не использовался. Если метод очень полезный, то всегда можно сделать прикладную функцию-обвертку, и уж она точно будет задокументирована. Хотя это уже будет выглядить еще более странно...
Может быть, нам с тобой и очевидно. Но если бы вопрос не был поднят, то ошибка бы не вскрылась. Таких прецедентов, скорее всего, совсем немного. Возможно, только этот метод и нужен оказался из всего, что убрали из объектной модели. А может быть и нет... Откуда знать об этом прикладным разработчикам? Вполне естественно, что общественность заинтересовалась.
По-моему, никто и не ждет, что тут будут озвучиваться какие-то обещания по изменениям платформы. Это неформальное общение, одна сплошная имха.
Пока что никто тут не говорил о системных доработках объектной модели. Речь идет о напрасно скрытом методе, который ИМХО открыть не так уж дорого, как ты это пытаешься изобразить.
На него даже документация уже написана, единственное что по стилям может быть не актуальна. Я, конечно, на истину в последней инстанции не претендую. Но если метод не откроют (и даже будут пугать вероятным отсутствием совместимости), то прикладники будут изобретать что-то свое наколенное. Меня даже разработчики стандартного DIRECTUMа уже про этот метод спрашивают. Написание прикладных функций для этой задачи выглядит несколько странным с учетом того, что все уже есть и работает, но когда-то сочтено не нужным. А как же твоя борьба с дублированием кода? 
А как же иначе?
Иначе будет скучно и пресно. У журналистов научился. Хотя, в данном случае, я не совсем с тобой согласен. Правильно я написал. Метод скрыли не потому, что он не использовался в стандартной версии, а потому, что решили, что он и не будет использоваться. Подумали что не нужен. До сих пор в стандартной версии DIRECTUM многое из открытой объектной модели не используется. Это же не стало причиной скрытия таких методов. 
Да, я согласен, что в составе ServiceFactory этот метод выглядит как-то странно. Такое ощущение, что надо было куда-то отнести, вот туда и засунули.
Т.е. убрали-то, возможно, правильно, неправильно то, что ничего взамен не дали. А метод мы как использовали, так и сейчас используем...
Вот именно для этих целей я и просил список скрытых методов :)
Тут я с Денисом полностью солидарен.
А давай рассуждать на основе фактов (тем более, что их легко получить), а не предположений?
Обещания здесь ни при чем. Я, как разработчик платформы, хотел бы понять для себя, когда я (чисто теоретически) мог бы заняться такими вещами. При текущем подходе мне этого не видно. Совсем.
У тебя есть альтернативный расклад по всем пунктам? Плюс прикидки того, как это наложить на загруженность разработчиков платформы и технических писателей?
А это вообще какое отношение имеет к обсуждаемой проблеме?
Мне не так уж легко, придется в техпроект тех самых изменений вчитываться. Оно того пока что не стоит. Я так понимаю, что ты с этим
предположением споришь? Если нет, то зачем тогда нужны мне эти пресловутые факты? А если да, то тем более, разработчикам не лишне было бы узнать, какие из этих напрасно скрытых методов реализованы потом в прикладной разработке заново.
Ты же любитель фактов, вот и посчитай во что нам обойдется возвращение метода.
Пока я тоже вижу одни голословные утверждения. Никто не говорит, что его надо возвращать завтра, но:
Итого, без внесения несовместимостей данный метод не убрать. И хорошей альтернативы ему сейчас нет.
Такое, что ты ничего пока что не предлагаешь, только говоришь - "всем молчать, обсуждать объектную модель бессмысленно, восстанавливать метод никто никогда не будет, т.к. дорого". Предложи тогда альтернативу. Сделать прикладную функцию? Вот тебе и дублирование. Других выводов из твоих слов пока что не вижу.
Денис, пока тут идет обсуждение, ты бы уже несколько раз успел запустить Delphi или Visual Studio и поискать слово Hidden.
Опять попытка манипулировать. Конкретно про трудоемкость открытия метода начал рассуждать ты, так что с тебя и факты.
Угу, вот только мои голословные утверждения опираются на мой ежедневный опыт работы. А твои на что?
В каком месте? Это как раз типовой подход: сделать прикладную функцию и объявить, что с заврашнего дня разрешено использовать только ее. Для того, чтобы исключить потенциальные проблемы, функцию включить в стандартную разработку.
Т.е. сделать новую функцию проще, чем открыть существующий метод, и дублирования кода тут не будет? Функция-то что должна делать? Вызывать этот скрытый метод? Странновато выглядит. Или же ты предлагаешь на ISBL написать заново то, что уже написано в самом билдере?
А лично меня этот вопрос и не интересует.
Мое предположение, на которое ты так ополчился звучало вот как:
И основано оно на том, что мой "ежедневный опыт работы" показывает, что разработчики платформы имеют достаточно квалификации для того, чтобы не скрывать что попало. Поэтому много таких вот "огрехов", когда скрыли то, что не надо было скрывать, быть не может. Ты с этим споришь или как? Прежде чем обвинять меня в манипуляциях, посмотри логическую цепочку своих рассуждений. А также цели, которых ты хочешь этими рассуждениями достичь.
Значительно. Не надо:
В общем читай эссе, на которое я давал ссылку (могу одолжить книгу). Его писал специалист, очень хорошо понимающий, что такое процесс production-разработки.
Где именно?
Почему?
Нет, не так. И не ополчился.
Вот поэтому:
В билдере в любом случае будет метод или функция получения относительного срока, т.к. это необходимо службе workflow. Мы либо дублируем эту функцию на уровне прикладной разработки (переписываем на ISBL, что неправильно т.к. это дублирование), либо используем билдеровский метод (что тоже неправильно, ибо он вроде как скрыт и без поддержки).
См. коммент: Андрей Подкин, 11 марта 2010, 15:03
Видимо, в данном случае возникло недопонимание.
В качестве обоюдного решения, может имеет смысл просто уведомлять прикладных разработчиков о методах которые перестают документироваться (изымаются из оборота
). Тогда разработчики смогут вовремя начать заменять их своими функциями, а если эти функции еще и выкладывать например здесь, это позволит существенно сократить время на переработку кода в будущем
. Тогда и "Волки" будут "сыты" и "овцы" почти "целы" 
.
Это аргумент для внешних разработчиков. Внутри компании договориться не проблема. Например, в 4.6.1 мы очень хорошо провели совместную работу над почтовой функциональностью. И как-то не напрягались из-за кардинальной смены внутренних механизмов.
Конечно. Например, без нового билда у тебя физически не появится нового метода в документации. Ибо такова технология и инструменты автоматизации. А без документации и смысла открывать нет.
Так в разрабатываемом или в текущем? Если в текущем, то в каком из? Хорошая система контроля версий + разделение разработки и поддержки здОрово првоцируют на множественные бранчи, знаешь ли
См. выше. Если мы выкинем этот метод, то расскажем, на что его заменить.
Авторизуйтесь, чтобы написать комментарий