JCo Server — JCoServerFunctionHandler — handleRequest — бесконечный вызов и TID

Реализовал JCo Server на Java, согласно примерам кодов (StepByStepServer).

Создал функцию внутри репозитория JCo Server.

JCo Server запускается нормально.

И я могу перехватывать запросы внутри следующего обработчика функций.

Вопрос 1) Нормально ли, что метод handleRequest в StfcConnectionHandler (реализация JCoServerFunctionHandler) вызывается непрерывно, как внутри бесконечного цикла?

Вопрос 2) Внутри handleRequest TID запроса ( serverCtx.getTID() ) всегда равен Null.

Отправляется ли TID со стороны SAP?

public class StfcConnectionHandler implements JCoServerFunctionHandler {

//Properties

@Override
public void handleRequest(JCoServerContext serverCtx, JCoFunction function) throws AbapException
{
        …// Endless call to this method
}

}

java sap jco
person Zeynal    schedule 06.06.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

В вашем вопросе недостаточно информации для более развернутого ответа.

Вопрос 1: Нет, это ненормально, конечно. Каждый удаленный вызов функции со стороны ABAP должен приводить к одному вызову handleRequest(...). Только в случае tRFC, qRFC или bgRFC может случиться так, что серверная часть ABAP повторит ранее неудачный вызов. Пожалуйста, проверьте, если это ваша собственная кодировка, которая выполняет эти повторяющиеся вызовы либо из ABAP, либо из Java. Здесь может быть полезно включить трассировки JCo и изучить их.

Вопрос 2: TID будет установлен только для вызовов tRFC и qRFC, но не для вызовов sRFC по умолчанию. Для bgRFC вместо TID будет установлен так называемый UnitIdentifier.

Я надеюсь, что это все же поможет.

*) Legend:
   sRFC  = synchronous RFC
   tRFC  = transactional RFC
   qRFC  = queued RFC
   bgRFC = background RFC
person Trixx    schedule 06.06.2017
comment
Спасибо за ответы. Если ABAP вызывает мою функцию (скажем, Z_TEST_FUNCTION), и я могу читать переменные импорта этой функции во время вызова в handleRequest. И я хочу откликнуться на этот призыв. Достаточно ли просто установить значение параметра экспорта (O_REQUEST_RESULT) функции Z_TEST_FUNCTION, например: function.getExportParameterList().setValue(O_REQUEST_RESULT, мой ответ на вызов Abap...); , я имею в виду, нужно ли мне делать что-то вроде function.Execute(jcoDestination)? - person Zeynal; 07.06.2017
comment
Да, вызов function.getExportParameterList().setValue(O_REQUEST_RESULT‌​, мой ответ на вызов Abap...); это все, что вам нужно сделать в реализации handleRequest(...). Параметры экспорта, изменения и таблицы отправляются обратно вызывающей стороне. Конечно, вы можете задавать только те параметры, которые также определены в интерфейсе вашей функции на стороне ABAP. Также обратите внимание, что tRFC, qRFC и bgRFC не могут отправлять обратно какие-либо возвращаемые параметры, это возможно только при синхронных вызовах RFC, когда вызывающая сторона ожидает ответа, чтобы обработать его. - person Trixx; 07.06.2017
comment
Спасибо за информацию! А также как я могу вызвать function.getExportParameterList().setValue(O_REQUEST_RESULT‌​‌​, мой ответ на вызов Abap...); из ручки Reuest? Я имею в виду, что мне нужно отправить сообщение в SAP. Это сообщение не является ответом на вызов SAP, это новый запрос на сторону SAP. - person Zeynal; 09.06.2017
comment
Как сказано, параметры экспорта, изменения и таблицы отправляются обратно вызывающей стороне. Это всегда выполняется автоматически при обработке sRFC JCoServer. Вы получаете объект JCoFunction в качестве аргумента в handleRequest(...). Я думаю, что теперь я ответил на ваш первоначальный вопрос, поэтому было бы неплохо, если бы вы также могли отметить его как принятый ответ. Если у вас есть дополнительные вопросы, например. как выполнять клиентские вызовы RFC с Java на ABAP, тогда не могли бы вы задать новый вопрос? StackOverflow — это не форум для долгих дискуссий. Спасибо. - person Trixx; 09.06.2017

arrow_upward
0
arrow_downward

Вопрос 1. Обычно вызов происходит в бесконечном цикле, но я видел это (не бесконечный, а с несколькими попытками), если ожидается, что запрос будет асинхронным, и вам потребуется слишком много времени для завершения handleRequest. Примером может служить реализация IDOC_INBOUND_ASYNCHRONOUS, когда я снова и снова получал один и тот же IDoc, потому что мне требовалось больше 3 секунд для обработки запроса (та же система занимала 3 минуты, когда я отправлял IDoc, но это другая история ;-)

Вопрос 2: Вы установили класс, реализующий JCoServerTIDHandler, как TIDHandler при настройке JCoServer? Без TIDHandler нет TID.

person Lothar    schedule 20.09.2017