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

на SDN был какой то блог, в котором достаточно подробно рассказывалось как толкнуть цепочку дальше... называлась тема типа "тра-ля-ля possible to restart a process chain тра-ля-ля" ...

Попробуй поискать там - может поможет..

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

Вообще-то в цепочках поддерживается ветвление по результатам загрузок, можно сделать логику пропускающую ряд шагов по результатам загрузки того или иного инфопакета.

Да нет, тут ветвление мне не надо. Просто ситуация такова, что я не знаю как поступать с данными в цели после момента самой ошибки. А с момента ошибки включаю "человеческий разум", шаманю ручками удаляю, добовляю, а затем продолжаю цепочку... но все равно всем спасибо

Зачем запускать цепочку после работы "человеческого разума"? Правильно настроенная цепочка должна продолжить работать дальше при ошибке в одной из загрузок, завершиться, а тебе отправить уведомление на мыло что в такой-то загрузке произошел сбой. Твоя задача сведется только к перезагрузке неудавшегося пакета.

У меня цепочка довольно запутанная... данные загружаются из ODS в ODS и т.д, причем присутствую варианты загрузки "из самого в себя". Самое страшное для меня - это сбой загрузки и идентификация состояния данных в целях на этот момент. Официальные курсы я не посещал, а на help.sap.com и в курсах четкого понимания не получил (читал и перечитывал ни раз). Нет там нормального описания относительно инициализации и дельты, все очень поверхностно (советы посетить курсы не принимаются - нет такой возможности).

В случае падения цепочки я не совсем понимаю механизм управления "выбор инициализации для исх. системы" и "статус инфо-витрины", когда их сбрасывать и как после этого корректно загружать данные и т. п. Помогите увязать эти понятия между собой, дайте ссылочку на нормальный документ или объясниите сами. Заранее спасибо.

...еще вопрос

запланирована цепочка процессов, данные обновляются в цели данных и остаются желтыми, и перехода на следующий процесс не происходит. В чем причина? Ошибок вроде нет. Количество записей около 1 000 000

смотри в мониторе

В мониторе ничего особенного... пишет что задание еще не завершено и все

жми "подробно"...
можно также глянуть дампы - ST22...

Все смотрел уже. У меня в правилах обновлениях используется расчет показателя, возвращающий таблицу. Есть ли какие-нибудь ограничения на размер такой таблицы? Может надо какие свойства инфо-пакета понастраивать?

sm 21 - посмотри, может быть место кончилось, st22 - дампы - может все таки есть? , sm50 - висит ли процесс, bd87 - вдруг заткнулся idoc и его надо руками пропихнуть

ST22

DBIF_RSQL_SQL_ERROR

-------------
Анализ ошибки
-------------

Es ist eine Ausnahme aufgetreten, die weiter unten nфher erlфutert wird.
Die Ausnahme, der die Klasse 'CX_SY_OPEN_SQL_DB' zugeordnet ist,
wurde in der Prozedur "WRITE_CHANGELOG" "(FORM)" weder abgefangen,
noch durch eine RAISING-Klausel propagiert.
Da der Aufrufer der Prozedur nicht mit dem Auftreten der Ausnahme
rechnen konnte, wurde das laufende Programm abgebrochen.
Der Grund fќr die Ausnahme ist:


-----------------------------
Указания по устранению ошибки
-----------------------------

Die Ausnahme muп entweder verhindert werden, innerhalb der Prozedur
"WRITE_CHANGELOG" "(FORM)" abgefangen werden oder
ihr potentielles Auftreten in der RAISING-Klausel der Prozedur
deklariert werden.
Um die Ausnahme zu verhindern, beachten Sie bitte folgendes:
Fehlertext der Datenbank...: " DSNT408I SQLCODE = -913, ERROR: UNSUCCESSFUL
EXECUTION CAUSED BY DEADLOCK OR TIMEOUT. REASON CODE 00C90088, TYPE OF
RESOURCE 00000D01, AND RESOURCE NAME 00016021.00000003 DSNT418I SQLST"
Internal call code.........: "[RSQL/INSR//BIC/AFARCUBE40 ]"
Please check the entries in the system log (Transaction SM21).

You may able to find an interim solution to the problem
in the SAP note system. If you have access to the note system yourself,
use the following search criteria:

------------------------------------------------------------------------
"DBIF_RSQL_SQL_ERROR" CX_SY_OPEN_SQL_DBC
"GP414Z4AG1BX2XDHL21B8Q4KHFN " or "GP414Z4AG1BX2XDHL21B8Q4KHFN "
"WRITE_CHANGELOG"

SM21 выдает примерно тоже самое


И куда тут копать?

Ноты 586100 821031
ты по ходу параллельно выполняемыми ветками в цепочках блокируешь процессы работающие с одними и теми же данными.
Всмомни Юлия Цезаря - Разделяй и Влавствуй!


Сделай несколько независимых цепочек и пускай одну за другой а не кашей в одной куче.