Как передать переменную из одного плагина в другой?

[SVK]

Задача: прервать каскадное выполнение некоторых плагинов при определенном действии.
Плагины на разных сущностях - т.е. шины разные.
Можно ли расшарить какие-то переменные между разными плагинами и как это сделать?
Что-то вроде SharedVariables на одной шине.

Коллеги, выслушаю любые идеи.

[a33ik]

Цитата:

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

Задача: прервать каскадное выполнение некоторых плагинов при определенном действии.
Плагины на разных сущностях - т.е. шины разные.
Можно ли расшарить какие-то переменные между разными плагинами и как это сделать?
Что-то вроде SharedVariables на одной шине.

Коллеги, выслушаю любые идеи.

Попробуйте использовать ParentContext.

[SVK]

ParentContext пустой для второго плагина, а установить его нельзя, судя по мсдн
"Remarks

This property is read only. "

[a33ik]

Цитата:

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

ParentContext пустой для второго плагина, а установить его нельзя, судя по мсдн
"Remarks

This property is read only. "

Тогда остаются только эксперименты.

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

[SVK]

1) При переназначении(assign) сущности Opportunity создаю сущность история сделки(new_opportunityhistory).

2) при создании сущности история сделки(new_opportunityhistory), обновляются некоторые поля сущности Opportunity.

Нужно, чтобы второй плагин, при таком порядке вызова, обновлял не все поля на сущности Opportunity.

Сейчас думаю, что можно как-то через базовый класс Request передать параметры, но пока не придумал как.

[a33ik]

Цитата:

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

1) При переназначении(assign) сущности Opportunity создаю сущность история сделки(new_opportunityhistory).

2) при создании сущности история сделки(new_opportunityhistory), обновляются некоторые поля сущности Opportunity.

Нужно, чтобы второй плагин, при таком порядке вызова, обновлял не все поля на сущности Opportunity.

Сейчас думаю, что можно как-то через базовый класс Request передать параметры, но пока не придумал как.

Понятно. Есть 2 идеи:
1. Используйте OptionalParameters.
2. В Вашем шаге 1 при создании сущности new_opportunityhistory создавайте какое то фиктивное поле-флаг, а в плагине Pre-Create этой сущности запоминайте, что поле пришло в контексте, убирайте его из контекста и передавайте дальше при помощи SharedVariables.
3. Мусорный, но на 100% рабочий. Создайте в сущности new_opportunityhistory служебное поле и при Вашем шаге 1 - заполняйте это поле, а на шаге 2 судите о наличии флага по наличию поля-флага в контексте.

Фокусов 1 и 2 я не делал, потому если это заработает - сообщите, пожалуйста.

[SVK]

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

[SVK]

Второй способ - валидатор не пускает - "\n 0x80041103\n 'New_opportunityhistory' entity doesn't contain attribute with Name = 'UpdateOppAfterHistory'.\n
Это при вызове Create до вызова плагина падает

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

Я не слишком искушен в программировании плагинов, но почему-бы не использовать IPluginExecutionContext.SharedVariables. Есть даже целый раздел SDK: Passing Data Between Plug-ins.

[SVK]

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

[SVK]

UPD. Иначе не стало - плагин теряет этот контекст для разных сущностей ((

[SVK]

Коллеги, я сделал это - передал что мне нужно, не используя базу )

Через следующую конструкцию
1) сделал промежутчную DLL для общих методов
2) реализовал статичный метод, через еоторый можно будет передавать статичные переменные

namespace Helper
{
    public static class Keeper
    {
        private static bool _UpdateOppAfterHistory = true;
        public static bool UpdateOppAfterHistory 
        {
            get { return _UpdateOppAfterHistory; }
            set { _UpdateOppAfterHistory = value; }
        }
        
    }
    public class OpportunityHelper
    { ... }
}

3) вызов производится следующим образом

 // Перед вызовом создания истории, устанавливаем флаг,
 // для плагина New_opportunityhistory.OpportunityHistory_Create
Keeper.UpdateOppAfterHistory = false;

OpportunityHelper.CreateOpportunityHistory(Opp,crmService);
                
// снимаем флажок обратно
Keeper.UpdateOppAfterHistory = true;

4) в плагине, который вызывается каскадом анализ переменной

bool UpdateOppAfterHistory = Keeper.UpdateOppAfterHistory;
if (UpdateOppAfterHistory)
{ ... }

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

Извините, не внимательно прочитал топик. Можете подробно рассказать что и как должно происходить? А то есть ощущение, что "код с душком". Если плагин на назначение создает какой-то объект, то пусть он сам и меняет сделку! Зачем вешать на "историю" дополнительный плагин с feedback? На мой взгляд это перегрузка логики служебного объекта.

[SVK]

Есть два разных случая:
1) Создание истории ВС вручную, открывается карточка и пользователь заполняет поля, при этом срабатывает плагин, переносящий заполненые поля с истории ВС на саму ВС.

2) Создание истории ВС автоматически, при переназначении ВС.

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

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

На этот случай у объекта есть такое поле isWorkFlowCreated.

[SVK]

У какого объекта?
У opportunity такого нету, у моего кастомного - тоже.
По SDK я вижу, что данное поле относится только к Activity разного типа и *close объектам.
Кроме того, оно разве относится к плагинам?