Sql Workflow Persistence Service не сохраняет состояние рабочего процесса - PullRequest
1 голос
/ 18 марта 2009

Привет всем,

Я имею дело с довольно странной ситуацией здесь. Я разработал рабочий процесс конечного автомата, и до сегодняшнего дня он работал нормально. Теперь Sql Workflow Persistence Service не сохраняет состояние рабочего процесса. Никаких исключений нет, просто это не спасает государство. Обычно поток переходит к действию, управляемому событиями, которое, следуя этой статье ссылка , является одним из условий, когда необходимо сохранить состояние рабочего процесса (то, что он делал просто отлично).

Конфигурация Sql Workflow Persistence Service выглядит следующим образом:

     <workflowRuntime name="WorkfolwServiceHostRuntime" validateOnCreate="true"
        enablePerformanceCounters="true">
        <services>
          <add 
            type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
                System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
                PublicKeyToken=31bf3856ad364e35" 
             connectionString="Data Source=svr; 
               Initial Catalog=WorkflowPersistence; user id=User;password=Pass; 
               Trusted_Connection=False" LoadIntervalSeconds="1" 
               UnLoadOnIdle="true"/>

        </services>
      </workflowRuntime>

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

Я не вижу никакой другой причины, по которой это происходит, поэтому буду признателен за любое предложение.

Спасибо

Ответы [ 3 ]

2 голосов
/ 30 марта 2009

Обычно рабочий процесс сохраняется, когда он становится бездействующим. Как скоро он будет сохранен, также зависит от таких факторов, как интервал опроса (который вы бы указали при создании SQLPersistenceService и присоединении его к среде выполнения.) Также все, что использует рабочий процесс, особенно. Аргументы и события ExternalDataEvent должны быть помечены как Serializable.

Что касается обработки исключений, вам следует добавить FaultHandlersActivity в ваш рабочий процесс, и обнаруженное исключение будет сохранено в свойстве Fault, которое отображается вместе с FaultHandlersActivity.

Надеюсь, это полезно.

0 голосов
/ 07 мая 2009

На самом деле вам не нужно удалять эти переменные, вам просто нужно поместить атрибут NonSerialized в его

0 голосов
/ 20 марта 2009

ОК, наконец-то я выяснил в чем проблема. В первом посте я писал, что сначала все работало так же, как очаровано, но после некоторых небольших изменений, которые не должны влиять на сохранение рабочего процесса, Sql Workflow Persistence Service не смог сохранить состояние в базе данных.

То, что я не упомянул, я представил рабочий процесс как службу WCF, и оказалось, что это крайне важно для решения этой проблемы. Я приношу извинения всем, кто пытался решить эту проблему с отсутствием информации.

Я использовал действие получения, которое указывал на метод контракта службы WCF. Этот метод возвращал значение сложного типа:

[DataContract]
public class ServiceCallInfo
{
    int code;
    [DataMember]
    public int Code
    {
        get { return code; }
        set { code = value; }
    }
    string message;

    [DataMember]
    public string Message
    {
        get { return message; }
        set { message = value; }
    }
}

Я связал это возвращаемое значение с новым свойством рабочего процесса.

public static DependencyProperty ReturnInfoProperty = DependencyProperty.Register("ReturnInfo", typeof(my.mynamespace.ServiceCallInfo), typeof(my.mynamespace.StandardContractingWorkflow));

    [DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)]
    [BrowsableAttribute(true)]
    [CategoryAttribute("Parameters")]
    public my.mynamespace.ServiceCallInfo ReturnInfo
    {
        get
        {
            return ((my.mynamespace.ServiceCallInfo)(base.GetValue(my.mynamespace.ReturnInfoProperty)));
        }
        set
        {
            base.SetValue(my.mynamespace.ReturnInfoProperty, value);
        }
    }

Если я только создаю экземпляр этого свойства где-то в коде рабочего процесса, Workflow Runtime не сможет сохранить состояние, и если я этого не сделаю, это состояние будет сохранено должным образом! Я предполагаю, что по какой-то причине Workflow Runtime не смог сериализовать (или что-либо еще, чтобы сохранить состояние с помощью Sql Workflow Persistence Service) состояние рабочего процесса из-за этого свойства.

Может быть, это из-за определения класса ServiceCallInfo, может быть, это что-то еще ... Я надеюсь, что кто-то с большими знаниями и опытом сможет сказать, каковы были реальные причины ...

Однако эта проблема решена.

...