Я пытаюсь реализовать механизм ведения журнала в гибридном приложении Service-Workflow.Требования к ведению журнала состоят в том, что вместо независимого действия в журнале каждый журнал должен рассматриваться как детальная операция и помещаться в родительскую / основную операцию.Таким образом, это parent-child и идет в таблицу (ы) базы данных.Это основная причина, не удалось NLog.
Чтобы лучше понять, я углубляюсь в общие детали.Вот как работает поток приложения:
Теперь главная точка входа приложения (обычно называемая Program.cs) - Платформа .Он инициализирует механизм, способный прослушивать входящие вызовы с линий ISDN, VoIP или веб-служб.Интерфейс является общим, поэтому любой вызов, который достигает Platform , вызывает OnConnecting () . OnConnecting () является потокобезопасным событием и может запускаться столько раз, сколько требуется системе.
В OnConnecting () , новый экземпляр нашего пользовательского рабочего процессаМенеджер запускается, и контекст представляет собой пользовательский объект с именем ProcessingInfo :
new WorkflowManager<ZeProcessingInfo>();
Где, ZeProcessingInfo:
var ZeProcessingInfo = new ProcessingInfo(this, new LogMaster());
Как видите, ProcessingInfo состоит из Platform и нового экземпляра LogMaster . LogMaster определен в независимой сборке.
Теперь этот LogMaster доступен для всего WorkflowManager , всех рабочих процессов, которые он запускает, всех операцийв любом запущенном Workflow и передается во внешний код, вызываемый из любого Activity .Теперь, когда инициализируется новый LogMaster , в базе данных создается запись Master Operation , и этот объект LogMaster теперь живет до тех пор, пока этот вызов не будет завершен после серииочень серьезные американские горки едет через различные рабочие процессы.При каждом вызове OnConnecting () создается и поддерживается новая основная операция.
LogMaster позволяет вызывать AddDetail () метод, который добавляет новые дочерние детали в мастер-операцию, хранимую внутри (различается через первичный ключ Guid). LogMaster построен на платформе Entity Framework.
И я могу войти под одной и той же основной операцией столько раз, сколько мне потребуется.Но требования к приложениям меняются, и теперь нужно регистрироваться с других сборок.Существует Platform Server сборка, которая является службой Windows, которая действует как сервер, слушающий вызовы на основе веб-службы, и как только клиент вызывает метод, OnConnecting в Platform срабатывает.
Мне нужен механизм для извлечения соответствующего объекта LogMaster, чтобы я мог добавить детали к той же основной операции.Но Platform Server один раз запускает OnConnecting () на Platform и, следовательно, создает экземпляр LogMaster .Это создает цикл избыточности.
Кроме того, также рассматриваются сценарии сбоев.В случае сбоя LogMaster необходимо вернуться к ведению журнала событий из журнала базы данных.Если запись в журнал событий не удалась (или не разрешена через унифицированную конфигурацию), необходимо вернуться к ведению журнала на основе файлов (XML).
Надеюсь, я дал приблизительную идею.Я не ожидаю кода, но мне нужна стратегия для очень плавного настраиваемого настраиваемого механизма ведения журналов, который поддерживает операции Master-Child.
Спасибо за чтение.Любая помощь будет высоко ценится.