Добрый день, помогите разобраться: в RSA3 данные выбираются корректно (полная загрузка). В BW запросы виснут в жёлтом статусе.
Данные отсутствуют.
Диагностика
The data request was a full update.
In this case, the corresponding table in the source system does not
contain any data.
Системные операции
Info IDoc received with status 8.
Процедура

Check the data basis in the source system.

Это частный случай с конкретным самописным экстрактором. Соединение ок, и полномочий у BWremote достаточно. IDOС's все зелёные. Честно говоря не знаю как их дальше анализировать. Смотрела только на статус, вижу что 0 записей передано, а что такое RQSTATE не знаю.
RQSTATE 0
RQRECORD 0
С виду нормальный экстрактор.
if s_counter_datapakid = 0.
выборка
else.
refresh e_t_data.
raise no_more_data.
endif.
s_counter_datapakid = s_counter_datapakid + 1.
Здесь проблем не вижу.
В экстракторе мы вызываем стандартный ФМ FKK_OPEN_ITEM_SELECT_WITH_DATE с внедрённым ENHANCEMENT POINT. Перед вызовом ФМ-ма из экстрактора мы передаём значение параметра set parameter id 'BI' field par_bi для отработки нужной ветки во внедрённом расширении (ФМ используем не только мы, для этого в логике его расширения и определяем свою ветку, которая отрабатывает только для нашего экстрактора). Может ли в этом быть дело? Можно ли использовать set/get parameter в экстракторах, или же с памятью лучше не связываться?

Подскажите, пожалуйста куда копать?

Не люблю этот мутный монитор.
Что в журнале задания в исходной системе?

Если экстрактор выдаёт совсем 0 записей, такое бывает, например. У меня было.

В таком случае нужно я делал дикий финт ушами. Выдаю пустую запись, потом в следующем цикле - raise no more data.

А покажите весь экстрактор, тег code не забудьте.

sm37 ?
Задание запущено.
Шаг 001 запущен (прогр. SBIE0001, вариант &0000000000892, пользов. ALEREMOTE)
Асинхр. отправка инфо-IDOCs 2 в задаче 0001 (0 паралл. задач(и)
DATASOURCE =: ZBI_720_FCT_ISU: :
*************************************************************************
* Актуальные значения выбранных параметров профиля *
*************************************************************************
* abap/heap_area_nondia......... 0 *
* abap/heap_area_total.......... 536870912 *
* abap/heaplimit................ 40894464 *
* zcsa/installed_languages...... ER *
* zcsa/system_language.......... R *
* ztta/max_memreq_MB............ 2047 *
* ztta/roll_area................ 3000320 *
* ztta/roll_extension........... 2000683008 *
*************************************************************************
Вызов расширения клиента BW_BTE_CALL_BW204010_E (BTE) с 0 записями(ью).
Результат расширения клиента: 0 записи(ей)
Вызов расширения клиента EXIT_SAPLRSAP_001 (CMOD) с 0 записями(ью).
Результат расширения клиента: 0 записи(ей)
IDOC: информ.IDOC 2, № IDOC 296155, продолжит-ть 00:00:00
IDOC: начало 17.03.2011 16:03:14, конец 17.03.2011 16:03:14
Синхронная отправка инфо-IDOCs 3 (0 параллел. задачи)
IDOC: информ.IDOC 3, № IDOC 296156, продолжит-ть 00:00:01
IDOC: начало 17.03.2011 16:03:14, конец 17.03.2011 16:03:15
Задание завершено.


К сожалению прав на редактирование экстрактора у меня нет, поэтому сама не могу проверить методом исключения что не так...

Отправила ЛС

Это взрыв мозга без отступов и подсветки сложно читать.

Вот как примерно должно быть.

Разница с Вашим упрощенным кодом принципиальная.

Прошу прощение за форматирование...
Да, код ещё тот не моё творчество. Но по структуре мы всегда так строили:


И проблем не было. И этот тоже при s_counter_datapakid = 1. e_t_data пустая.
Можно как-ть ещё протестировать вызов экстрактора из BW? Как понять, где проблема?

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

Именно так и делала - никаких проблем в RSA3 не нашла. Экстрактор отрабатывает корректно возвращает записи достаточно быстро. Вот поэтому и спрашиваю возможна ли проблема из-за передачи параметра при вызове из BW? В остальном я не нашла к чему предраться (пока оптимальность кода не обсуждаем:))

Это как? вручную заполняли e_t_data?

Ну да. Это такая же внутренняя таблица, тип её известен. Туда можно добавить запись.

Кроме того, пакет на котором проходит raise no more data - он не берётся в BW. То есть, нужно выдать минимум два пакета. С одной записью, а на следующем подать raise no more data.

Важно только то, какие данные фм на каком шаге возвращает, что внутри происходит неважно (в общем и целом )
Первый вызов - инициализация.
Второй вызов - возврат номера пакета "1" и данные в E_T_DATA (количество строк регулируется параметром).
Третий вызов - возврат номера пакета "2" и данные в E_T_DATA.
и т.д. пока есть что возвращать, иначе райзит.

Теперь по делу, функциональный модуль вызывается два раза? и все данные возвращает в одном пакете (при втором вызове)? сколько строк он возвращает?

Yanvladimirovich, опередил

Это понятно. Смогла бы добавить будь у меня ключ разработчика. Абаперам в очередь поставили доработку


Где я могу посмотреть количество пакетов?
http://rapidshare.com/files/453014446/2 ... 201650.jpg
Не получилось вставить картинку: в подробной информации монитора:
Перенос (Idocs и Trfc): Все в порядке (ЗЕЛЁНАЯ ВЕТКА)

Idoc запроса : Документ приложения проведен.
Инфо-Idoc 2 : Документ приложения проведен.
Инфо-Idoc 1 : Документ приложения проведен.
Инфо-Idoc 3 : Документ приложения проведен.

А вот дальше: Обработка (пакеты данных):
Данных нет (Жёлтый)

Тестировала в RSA3, ФМ вызывается 3 раза:
1. инициализация
2. забирает данные
3. При sy-subrc = 1, s_counter_datapakid =1 . В экстрактор заходит : refresh e_t_data. raise no_more_data.

да верно

30