none
Не удаётся преобразовать переменную. RRS feed

  • Вопрос

  • Доброго времени суток.

    Подскажите пожалуйста, каким образом записать данные в переменную, чтобы, когда из неё извлекались данные получались несколько значений?

    Пример: Задача начать процесс утверждения с разным набором руководителей. Набор руководителей меняется в зависимости от пользователя создавшего элемент в списке. Руководители определяются и каждый записывается в свою переменную:

    Найти руководителя для ExampleUser (с выводом в Переменная: Руководитель 1го уровня )

    Найти руководителя для Руководитель 1го уровня (с выводом в Переменная: Руководитель 2го уровня )

    Найти руководителя для Руководитель 2го уровня (с выводом в Переменная: Руководитель 3го уровня )

    Затем необходимо всех руководителей объединить в одну переменную, к примеру "Список рассылки", чтобы потом в действии ниже можно было бы из этой переменной вытащить адреса электронной почты:

    Начать процесс Утверждение для Текущий элемент с набором пользователей Переменная: Список рассылки

    Подскажите каким образом это возможно сделать? Пробовал сохранять данные вот таким образом:

    А извлекать таким:

    Рабочий процесс выдаёт ошибку:

    Ошибка приведения: Не удалось преобразовать входные данные подстановки к запрошенному типу.

    Что я делаю не так?

    Благодарю заранее за любую информацию.

    27 октября 2014 г. 5:02

Ответы

  • Мне кажется логичней будет так:

    или так:

    для типа подстановки используйте: адрес электронной почты

    суть в том что у вас 3 разных РП запускается
    1. Если все заполнены
    2. если заполнены 2
    3. Если заполнен 1 руководитель.

    В каждом из РП прописанны соответсвующие переменные одна две или три.

    27 октября 2014 г. 12:02

Все ответы

  • я попробую только пофилософствовать.

    Предлагаю разбить задачу на 3 этапа. Сначала определиться, что руководитель первого уровня находится без проблемм.

    Далее эту переменную записать в любое новое поле типа текст. Посмотрите в каком виде оно пишется. Дисплей нейм или юзер аккаунт?

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

    Третий этам уже создать рассылку. 

    27 октября 2014 г. 8:24
  • Андрей, спасибо за ответ.

    Наверное, мы друг друга не поняли. 

    Выполняю процесс по вашим рекомендациям:

    1) Определяется руководитель без проблем

    2) Записывается в формате юзер аккаунт в переменную "руководитель"

    3) Действие третьего пункта не понял. 

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

    27 октября 2014 г. 10:16
  • Мне кажется логичней будет так:

    или так:

    для типа подстановки используйте: адрес электронной почты

    суть в том что у вас 3 разных РП запускается
    1. Если все заполнены
    2. если заполнены 2
    3. Если заполнен 1 руководитель.

    В каждом из РП прописанны соответсвующие переменные одна две или три.

    27 октября 2014 г. 12:02
  • Смотрите если Вы уверенны что все переменные вы определили правильно. Что Вам мешает сделать рассылку переменная1;переменная2;переменная3 в поле TO.  Во первых Вы забыли поставить точки с запятыми.

    Во вторых судя по скриншеты Вы не рассылку используете а на трех руководителей пытаетесь повесить задачи.

    Если просто им хотите отправить письмо то используйте активность send email.

    27 октября 2014 г. 12:30
  • Мне кажется логичней будет так:


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

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

    Решилось всё просто - после записи всех руководителей в переменные начинается процесс утверждения для каждой из них последовательно. Тем переменным которые оказались пустыми (в случае отсутствия руководителей 2го,3го и т.д. уровней) задачи не назначаются, РП утверждения автоматически пропускает их.

    28 октября 2014 г. 3:20
  • Смотрите если Вы уверенны что все переменные вы определили правильно. Что Вам мешает сделать рассылку переменная1;переменная2;переменная3 в поле TO.  Во первых Вы забыли поставить точки с запятыми.

    Во вторых судя по скриншеты Вы не рассылку используете а на трех руководителей пытаетесь повесить задачи.

    Если просто им хотите отправить письмо то используйте активность send email.

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

    Насчёт точки с запятой спасибо, этот вариант я попробую, если получится, то отпишусь здесь же.

    28 октября 2014 г. 3:27
  • Коллега Вам правильно схему выстраивал. Проверяя на пустоту. Дело в том, что это не РП обходит и пропускает руководителей которых не нашел. На самом деле Вам повезло что все не сваливается в ошибку. Уверен что в логах РП есть записи что происходит ошибка... Вообще в РП дизайнера всегда инициализируйте переменные если Вы что то с ними делаете. Например на пустоту назначаете РП.
    28 октября 2014 г. 4:40
  • Да, я понимаю что правильнее будет не допускать пустых переменных в любом процессе, но в тоже время считаю что на каждую проверку пустой переменной создавать РП не целесообразно. А если в организации будет десятиступенчатая система руководства? На каждую ступень назначать процесс?

    Правильное решение мне видится следующим, проверяем каждую переменную "руководитель№" на пустоту, и в зависимости от проверки записываем в новую переменную "Список рассылки" все переменные "руководитель №-1". Пример на картинке:

    А потом уже начинать РП утверждения для текущего элемента с набором пользователей Переменная: Список рассылки.

    Вот с этим пунктом беда, я не знаю с помощью какой подстановки мне записать значения нескольких переменных типа "руководитель №" в одну переменную типа "список рассылки", таким образом, чтобы потом, эту переменную - "список рассылки" подставить в поле "участники" РП утверждения. Я уже кучу вариантов перепробовал, но SPD не смог вытащить из переменной "список рассылки" необходимые данные. Выдаёт ошибку: Ошибка приведения: Не удалось преобразовать входные данные подстановки к запрошенному типу.

    28 октября 2014 г. 6:06
  • что то вы совсем себе усложнили все!

     Ошибка приведения: Не удалось преобразовать входные данные подстановки к запрошенному типу. - эта ошибка вполне может возникнуть из-за пустых значений.

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

    Удачи.

    28 октября 2014 г. 8:02