Прошу прощения, не исключено, что вопрос прозвучит или глупый или очень простой.
Как отладить экстрактор с дельта очередью?
Поясню.
Есть простой кастомный экстрактор, который построен на ракурсе из таблицы cosp. Кроме того, в этом экстракторе включена дельта по полю, типа timestamp.
Инициализация дельты прошла и данные в dso загрузились.
Через пару недель запускаю дельта-пакет, долгие раздумья и 0 записей. Дату последней загрузки - обновляет, пакет ставит зеленым.
Смотрю на ERP транзакцию RSA7 и значение дельта-очереди для моего экстрактора - там есть значение дата-время (11.10.2010 15:13:33 - Время ввода (Greenwich Meantime)).
С помощью ФМ RKE_TIMESTAMP_CONVERT_INPUT конвертирую 12.10.2010 10.10.10 (вообще конвертирую как московское время, но с учетом, что я для надежности целые сутки накинул - должно быть все равно, гринвич ли в дельте и гринвич ли в таблице) в 6.557.118.100.000
Беру в se11 с ограничением 250 записей, что cosp, что свой ракурс, с ограничением timestamp = [6.557.118.100.000 - 7.557.118.100.000] - записи есть (они и должны быть).
Пробую RSA3 в режиме "дельту к последнему пакету", оно думает, потом валится в дамп с динамической ошибкой по тайм-ауту.

Три вопроса:
1. Что и как еще проверить?
2. Есть ли возможность провалиться в отладку экстрактора не из RSA3, а при вызове пакета из BW, чтобы посмотреть, что происходит именно при вызове из BW, ведь если оно и в этом случае будет дохнуть по тайм-ауту, то пакет должен быть красным?
3. Может я что-то забыл включить или там настроить?

Может кто сталкивался с похожими проблемами. А я еще попробую все же провалиться в дебагер - хотя бы посмотреть, что за timestamp передается для дельты (тут еще выяснил, что таймстэмпы бывают вполне разные и что вид таймстэмпа из дельты может и не совпадать с видом таймстэмпа в таблице - это действительно так?).

Большое спасибо за ответ.
Но та тема ко мне отношения имеет мало, поскольку там девушке предлагают проверить такие вещи, как запускала ли она вообще инициализацию дельты и т.д. А потом она написала, что проблему решила сама, но не написала как (прямо сильно не люблю таких ...).

Тем не менее дело сдвинулось с мертвой точки.
В дебагере стало понятно, что BW метку времени передает во внутреннем формате, который даже в хелпе описан как YYYYMMDDHHMMSS + кажется еще милисекунды в длинном формате... и все это по Гринвичу... это элемент данных TIMESTAMP с доменом TZNTSTMPS.

А вот в cosp поле TIMESTMP имеет элемент данных RKE_HZSTMP с доменом RKE_TSTMP, который описан как количество секунд с 01.01.1900 по текущее время по Гринвичу и умноженное на 10000 (и есть ФМы для работы с такими значениями - RKE_TIMESTAMP_CONVERT_OUTPUT и RKE_TIMESTAMP_CONVERT_INPUT).

Таким образом, я вижу две возможности - указать в дельте это поле как цифровой указатель или делать экстракцию на базе ФМ, в котором обрабатывать передаваемое значение, преобразуя его к нужному формату.

Собираюсь попробовать вариант с цифровым указателем, но может кто-то предложит еще варианты или обоснует преимущества использования ФМ?

Имхо, первое предложение - использовать стандарт. Если он не устраивает, понять какая доп. функциональность требуется, позволяет ли ее реализовать обсуждаемый вариант или использование ФМ и т.д. Из темы это не ясно. А если есть свободное время и желание зарыться в код, то тогда другое дело, в CO-экстракторах немало особенностей.

ну дельта на базе FM - это тема, которую SAP не реализовал нормально.

Да, ссылку не ту дал.


С помощью ФМа выборка дельты может идти быстрее за счет правильно построенного SQL - запроса. К тому же в будущем возможно придется расширять экстрактор данными не из COSP.

Интересно как выглядит

для
?


согласен с Online

Прошу прощения, что "прозевал" ответы в теме.
Дело в том, что стандартную экстракцией из CO-PA делали коллеги с другого проекта на этом же клиенте. Дельта у них таки не заработала, в компетенции их нет никаких сомнений, скорее всего кривизна стандартной реализации (на таких объемах данных) или кривизна настройки ERP (не получается повлиять), но там дельта висит 4 часа и потом падает.

если на ракурсе не получится, то как вариант:
1. взять за основу стандартный экстрактор, скопировать, сделать свой и его "подпилить" так, чтобы он работал.
2. если есть BTE-события для CO-PA, то реализовать сбор дельты на BTE (how-to есть на sdn ...)

Насчет sql запроса - возможно (там все же еще из CE4 аналитики подтягиваются). Но пока построил просто на базе ракурса, выбирает (инит дельты, дельту) очень долго (что ожидаемо, т.к. на TIMESTMP нет индекса, а записей очень много), но сейчас возник вопрос вообще в принципиальной необходимости этих данных и отчета на них, так что пока смотрим, может вообще отвалится проблема.

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


Я вот пока не смог найти ответственного за настройку CO-PA и неясно, что там есть, но зато "все" говорят, что настроено далеко не полностью. Про BTE почитаю для своего развития, спасибо.