Отлов Assign

[ShurikEv]

Добрый день.
Вот я столкнулся с первой проблемой, а может быть и глюком...
В общем, надо уведомлять о назначении менеджера ответственным. Реализовал ф-ю уведомления. Есть 2 варианта: делать через callout или через WorkFlow. Далее есть 2 варианта: изменять назначение из формы или из кода.
Рассмотрим ситуации:
1. Из формы
- callout: сработало правило 1 раз
- WorkFlow: сработало правило 1 раз
2. Из кода (назначение как меняется так и остаётся преждним, но в обоих случаях заполняем поле ownerid) - внешняя сборка, допустим консольное приложение.
- callout: сработало правило 0 раз
- WorkFlow: сработало правило 2 раза
У кого какие мысли?
Полез в SDK

ЗЫ MS CRM 3.0

[tatra]

Я идентичную задачу у нас сделал колаутом. Работает как часики.

Конфиг должен так выглядеть.
.....................
<callout entity="account" event="PostAssign">
<subscription assembly="CallOutSendMail2003.dll" class="SendMessageCallOut.Verify">
<prevalue>ownerid</prevalue>
<postvalue>ownerid</postvalue>
</subscription>
</callout>
<callout entity="task" event="PostAssign">
<subscription assembly="CallOutSendMail2003.dll" class="SendMessageCallOut.Verify">
<prevalue>ownerid</prevalue>
<postvalue>ownerid</postvalue>
</subscription>
</callout>
<callout entity="contact" event="PostAssign">
<subscription assembly="CallOutSendMail2003.dll" class="SendMessageCallOut.Verify">
<prevalue>ownerid</prevalue>
<postvalue>ownerid</postvalue>
</subscription>
</callout>
<callout entity="opportunity" event="PostAssign">
<subscription assembly="CallOutSendMail2003.dll" class="SendMessageCallOut.Verify">
<prevalue>ownerid</prevalue>
<postvalue>ownerid</postvalue>
</subscription>
</callout>
<callout entity="campaignresponse" event="PostAssign">
<subscription assembly="CallOutSendMail2003.dll" class="SendMessageCallOut.Verify">
<prevalue>ownerid</prevalue>
<postvalue>ownerid</postvalue>
</subscription>
</callout>
</callout.config>
-----------------------------------------------------------------

Пример кода колаута

namespace SendMessageCallOut
{
publicoverridevoid PostAssign(CalloutUserContext userContext, CalloutEntityContext entityContext, string preImageEntityXml, string postImageEntityXml)
{
тра та та - отправка сообщения (создает письмо в CRM отправляет и удаляет его из CRM) - пример кода создания писем есть в SDK.
}


...............................

[ShurikEv]

Т.е. никто больше глюков не наблюдал?
Уважаемы, tatra. А вы пробовали программно менять назначение? callout'ы срабатывают? Конфиг я-то прописал правильно ;-) Это видно хотя бы из того, что callout срабатывает при смене ответственного на форме. А вот из кода - фиг. Для проверки у меня сейчас стоит простая запись в лог.

[tatra]

Ладно , понятно. Я этим вопросом не занимался. Но мне кажется нужно отправлять письмо там же где и происходит Assign программно.

[ShurikEv]

А может кто-нибудь кому не сложно произвести этот опыт у себя? Чтобы стало понятно, что это за такое: бага или у меня что-то где-то не то
Спасибо.

[Likefire]

Цитата:

Сообщение от ShurikEv

А может кто-нибудь кому не сложно произвести этот опыт у себя? Чтобы стало понятно, что это за такое: бага или у меня что-то где-то не то
Спасибо.

Если не сложно - поясните суть проблемы более предметно. Преподнесите условие задачи более целостно - тогда не лень будет и воспроизвести.

[ShurikEv]

2Likefire
Еще раз объясняю Тестирую функционал Assign. Для этого написал callout и WF-функцию. Сделал, чтобы они срабатывали при назначении ответственного. При срабатывании пишу в лог информацию (к примеру, Id объекта - не суть важен какой объект, главное чтобы имел ответсвенного). Так вот при смене ответсвенного
1. Из формы
- callout: сработало правило 1 раз
- WorkFlow: сработало правило 1 раз
2. Из кода (назначение как меняется так и остаётся преждним, но в обоих случаях заполняем поле ownerid) - внешняя сборка, допустим консольное приложение.
- callout: сработало правило 0 раз
- WorkFlow: сработало правило 2 раза
Видно, что когда манипуляции производятся из кода, то реакция не ожиданная.

[ShurikEv]

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

account acc = new account();
acc.accountid = new Key();
acc.accountid.Value = new Guid("601D7FB6-68CD-DC11-8940-0003FF0A1ABB");
acc.ownerid = new Owner();
acc.ownerid.type = EntityName.systemuser.ToString();
acc.ownerid.Value = new Guid("B05A92E4-E97B-DC11-8490-0003FF0C1ABB");
service.Update(acc);

В остальном без изменений.

[Likefire]

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

[ShurikEv]

Всякие Pre/Post Update/Create/Delete срабатывают...

[Артем Enot Грунин]

Callout - расширения бизнес логикой платформы и с формой никак не связаны! Cрабатывать они должны всегда, например, при выходе из автономного режима.
Проблема может быть в том, что вы используете не те ф-ции. Формально событие изменения записи, смены состояния и переназначения - это разные события! Если вы просто подменяете GUID в коде, что вы и делаете, то событие будет UpDate!!! Чтобы сработало Assign надо использовать соответствующую ф-цию. Что-то вроде AccountTargetAssign, наверно - под рукой сейчас нет SDK.

[ShurikEv]

Если вы имели ввиду связку TargetOwnedAccount/AssignRequest, то это же для назначения доступа (дать доступ группе/пользователю). Это никак не меняет ответственного.
И я считаю, что всякие методы типа TargetХХХRequest/Response - это просто тоже самое, что и Create/Update/Delete, но другими словами. Кому как удобно, тот так и использует.
Но я всё равно поищю подходящую функцию. Но опяться же: почему WF сработало, а Callout нет? Вот что для меня странно. Т.е. WF поняло, что произошла смена ответсвенного (даже если он не поменялся ), а вот для Callout это не так (даже когда ответственный меняется). Налицо, какое-то несоответсвие логике

[ShurikEv]

Прошу прощения за проявленную некомпетентность
Связка TargetOwnedAccount/AssignRequest/AssignResponse повела как нужно: из кода и из формы вызвала ровно по 1 разу и WF и Callout.
Спасибо.

[Артем Enot Грунин]

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

[ShurikEv]

Вот про 4.0 тоже пока не совсем всё гладко пока для меня. Есть WF, которые теперь WF+Callout. Но там же еще есть и plugin's. Вот что это за зверь, для меня пока тайна. Тайна, т.к. с 4кой практически не работал...

[AndreyS]

Поправлю:
Callout-ы и WF перешли на единую платформу, но это два различных способа настраивать бизнес-логику. WF задается с помощью интерфейса бизнес-процессов и расширяются с помощью WWF активностей. Plugin-ы (в 3.0 - callout-ы) работают на платформенном уровне.

[ShurikEv]

AndreyS вот именно так мне это и показалось. Но вечные фразы, что "Callout и WF слились воедино" наводило на мысль, что от callout отказались, а заменили WF. Теперь ясно хоть.