Вызов AIF сервиса в отдельном соединении

[sgt.Pepper]

Всем добрый день,

есть одна проблема, которая заключается в следующем:
при вызове AIF custom сервиса происходит импорт данных, во время которого пишутся логи. НО: если хоть где-то в коде выбросится ошибка или вызов ttsabort, то соответственно ни лога, ни данных...

Если бы это была одна какая-то таблица, я не задумываясь использовал бы UserConnection, но здесь сервис вызывает класс, который выполняет всю логику, поэтому классу я передать соединение не могу, к тому же класс написан внешниками и зашифрован при помощи макросов (можно конечно парсер написать, но по лицензионному соглашению запрещено).

Есть предложение от коллеги использовать anonymous pipes, примерно вот так:

        pipeServer = new System.IO.Pipes.AnonymousPipeServerStream(System.IO.Pipes.PipeDirection::Out
                                                                    , System.IO.HandleInheritability::Inheritable);

        thread = new Thread();
        thread.setInputParm([clr2XppStr(pipeServer.GetClientHandleAsString())]);
        thread.removeOnComplete(true);
        thread.run(classNum(ApIpcExample), staticMethodStr(ApIpcExample, messageReader));
        pipeServer.DisposeLocalCopyOfClientHandle();

но не уверен, что в этом случае будет использоваться отдельное соединение.

Может кто сталкивался с подобной проблемой?

[DSPIC]

это известная проблема X++, когда выполнение кода просто прерывается без возможности отлова исключений. Чаще всего происходит при вызовах внешнего кода.
Знаю два варианта решения:
#1: На C# пишем простую функцию, которая вызывает внешний сервис (или, в общем случае, любой, потенциально нестабильный внешний код). Функция будет вызывать внешнюю 1:1 как бы вы это делали из X++. Но на C# вы делаете полноценный try/catch, который гарантированно вернет управление обратно в АХ. Функцию подключаем как .net reference в АОТ и юзаем. Это решение простое и надежное, правильное. Но получаем все нюансы использования .net references, что требует бережного обращения, в зависимости от версии АХ
#2 реализовать класс MultithreadHandler, который: 1) запустит необходимое кол-во потоков в асинхронном режиме 2) периодически, опрашивая их статус, дождется их окончания 3) в зависимости от того, вернул поток результат, либо скоропостижно скончался (это можно отследить в классе Thread), залогирует соотвествующий результат. Тут правда, в отличие от первого способа, вы никогда не узнаете, от чего поток умер (или какое исключение вернул внеший вызов)
#3 Гм, или я не понял задачу ,

[sgt.Pepper]

Спасибо за совет, идею понял. Если сформулировать точнее, то проблема заключается в следующем:
на вход импорт-класса я последовательно скармливаю XML-и, которые должны в определенной последовательности обрабатываться.

Скажем, у меня есть 5 XML-ей:
подал первую - скушал,
подал вторую - скушал,
на третьей подавился, выбросил ошибку, оборвал транзакцию, в итоге вся информация про 1-ю и 2-ю вместе с логами пропали, поскольку вызов сервиса происходит в контексте одной транзакции.

Значит теоретически я могу, используя метод #2, для каждого прохода открыть новый поток и в нем новое соединение? Или все открываемые потоки будут обрабатываться как одна транзакция?

[Link]

Если я правильно понял проблему, то я бы смотрел в сторону модификации AIF - так что бы каждый вызов внешнего класса выполнялся отдельной транзакцией, но это мне видится далеко не тривиальной задачей. К тому же, лог в этом случае, вероятно будет потерян. Другой вариант - изменить принцип логирования\обработки исключений во внешнем классе. Можно, например в случае исключения отсылать лог Аксапте через другой простенький AIF сервис.

[Vadik]

Нельзя несколько вызовов AIF завернуть в некую внешнюю транзакцию. Но, как вариант, можно упаковать несколько документов в одно сообщение - смотрите в сторону Processing batched messages in AIF [AX 2012]

[Alex_KD]

Цитата:

можно упаковать несколько документов в одно сообщение

Насколько я понял речь идет про custom сервис, а не стандартные AIF документы.

Цитата:

НО: если хоть где-то в коде выбросится ошибка или вызов ttsabort, то соответственно ни лога, ни данных...

Можно выйти из транзакции которую AIF создает (ttscommit), try/catch вокруг вызова вашего класс и зайти обратно (ttsbegin). Также проверьте appl.ttsLevel(). Класс должен правильно с транзакциями работать (открывать-закрывать).

Посмотрите как AIF вызывает ваш метод в AifWcfProcessor, сделайте трейс.
И как транзакция открывается/закрывается -

AifRequestProcessor.processWcfRequest - AIF делает ttsbegin в конце
AifRequestProcessor.processWcfResponse - AIF делает ttscommit в начале

Имейте ввиду что AIF логика может быть разная для Basic и Enhanced портов.

[ex3em]

В методе который выполняется AIF запускайте thread.

[sgt.Pepper]

Если кому интересно, нашел решение проблемы (спасибо подсказке Alex_KD).

При вызове сервиса AIF создает "глобальную" транзакцию, соттветственно если что-то случается в самом сервисе, все try-catch блоки самого сервиса просто игнорируются и идут выше в обработчики AIF, где собственно было начало транзакции. Все попытки использовать catch Error, ClrError, Internal и просто catch не увенчались успехом.

Что сделано:
в точке входа сервиса сделал проверку на уровень tts и сразу сделал ttscommit.

ttsInitialLevel = appl.ttsLevel();
if(ttsInitialLevel > 0)
{
    ttscommit;
    ttsbegin;
}
...

Дальше открыл свою транзакцию и запускаю логику. Если код где-то валится, то управление уже не передается выше в AIF, а срабатывают свои обработчики.

После отработки метода делаю ttscommit своей транзакции, и перед возвратом создаю новую.

if(ttsInitialLevel >0 && appl.ttsLevel() == 0)
ttsbegin;
return something

Так можно обмануть систему.

[Dreadlock]

Цитата:

Сообщение от sgt.Pepper

Если кому интересно, нашел решение проблемы (спасибо подсказке Alex_KD)...

Немного доработайте свой код, т.к. ttsLevel может быть и > 1

[sgt.Pepper]

Ну я собственно с единицей нигде не сравниваю, проверяю только, что транзакция открыта (ttsInitialLevel > 0)
А в чем вы видите ошибку?

[Dreadlock]

ttsBegin у вас один, когда все транзакции возвращаетесь

[sgt.Pepper]

Вы правы, надо будет что-то вроде такого написать

for (i==1; I<= ttsInitialLevel;i++)
    ttsbegin;

Только я ни разу не заметил начального уровня больше чем 1. Думаю он открывается в AIF только один раз, но на всякий случай проверю.

[Dreadlock]

Цитата:

Сообщение от sgt.Pepper

Вы правы, надо будет что-то вроде такого написать

for (i==1; I<= ttsInitialLevel;i++)
    ttsbegin;

Только я ни разу не заметил начального уровня больше чем 1. Думаю он открывается в AIF только один раз, но на всякий случай проверю.

Береженого бог бережет
Сегодня Вы не видите несколько транзакций, сделаете как вам видится, уволитесь, пройдет 5ть лет и кто-нибудь влезет в этот механизм, потом пол компании будет затылок чесать: "а что же произошло"?

P.S. Может вместо ttsAbort написать ttsCommit?

[sgt.Pepper]

Вообще-то я нигде не писал ttsAbort, а при перехвате исключения ttsLevel итак сбрасывается на 0.
А через 5 лет наверно и X++ уже не будет.

[Dreadlock]

Цитата:

Сообщение от sgt.Pepper

Вообще-то я нигде не писал ttsAbort, а при перехвате исключения ttsLevel итак сбрасывается на 0.

Упс, писал в метро на скорую руку

Цитата:

Сообщение от sgt.Pepper

А через 5 лет наверно и X++ уже не будет.

Поверьте мне, Ах стоит в компаниях годами, я сам сейчас на проекте, где Ах 3.0 уже 16 лет исправно служит добрую службу.

[Link]

Вот еще по теме: Preserve data when AIF service call fails

Dynamics AX AIF is great for all kind of interfaces and integration with 3rd party applications. By default AIF has an built-in transaction mechanism that prevents your system to become inconsistent if something goes wrong during processing.

Here is an example of a simple method which writes message data and the current transaction level into a table

    [SysEntryPointAttribute]
    public void call(Description _message)
    {
        ERPServiceTable serviceTable;

        serviceTable.Message = _message;
        serviceTable.Info = strFmt("%1", appl.ttsLevel());
        serviceTable.insert();
    }

Here is the service call from a C# console application

PHP код:

    var client = new ERPService.ERPServiceClient();
    client.ClientCredentials.Windows.ClientCredential.Domain = "YOUR_DOMAIN";
    client.ClientCredentials.Windows.ClientCredential.UserName = "YOUR_USER";
    client.ClientCredentials.Windows.ClientCredential.Password = "YOUR_PASSWORD";

    var context = new ERPService.CallContext();
    context.MessageId = Guid.NewGuid().ToString();
    client.call(context, "Service Call"); 


When you call the service the result looks like this: Notice, the transaction level is already 1 although there is no ttsbegin in code.

AIF service call

But what happens when something goes wrong during processing the service call (e.g. posting a journal fails). Here is as simple method which can be used to simulate such a situation:

    [SysEntryPointAttribute]
    public void callWithError(Description _message,boolean _error)
    {
        this.call(_message);
        if(_error)
        {
            throw error("Exception!");
        }
    }

When you call the service method with the error flag set to FALSE, the message is written to the table and stays there.

    context.MessageId = Guid.NewGuid().ToString();
    client.callWithError(context, "Service Call without error", false);

However if you call the method with the error flag set to TRUE a rollback is triggered and your data is gone!

    try
    {
            context.MessageId = Guid.NewGuid().ToString();
            client.callWithError(context, "Service Call 2 with error", true);
    }
    catch
    {
            Console.WriteLine("The service failed as expected!");
    }

The table contains only 2 entries for both successful service calls. The data from the third service call is gone.

Service call with error not saved

However, if you want to keep the initial data for a post mortem analysis, this behavior is a problem. One way to work around this rollback is to reduce the transaction level back to 0 by calling an additional ttscommit. This will ensure no rollback will delete the transmitted data. Finally, raise the ttslevel back to 1 for further processing.

    [SysEntryPointAttribute]
    public void callWithError(Description _message,boolean _error = false)
    {
        this.call(_message);

        ttsCommit;
        ttsBegin;
       
        if(_error)
        {
            throw error("Exception!");
        }
    }

When you call the service method with the error flag set to true, the method still fails. But the initial transmitted data is preserved and can be used for analysis or manual processing.

Service call with error preserverd
BTW.

A more relaxed way to address this issue is to separate interfaces from business logic. For example provide two methods, one to transmit the data and another to process the data after it was successfully transmitted. If a second method is not an option (for what reason ever) write a batch class which processes the data. However, if you require immediate processing and a second call is not feasible this workaround may help.