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

куда глянуть? какой ФМ, таблицу? Пните плиз в нужном направлении

Только абапом. Таблица UPS_CHANGELOG

да, за это время я пересмотрел кучу таблиц и модулей, в частности и UPS_CHANGELOG. В ней указаны изменения статусов. это хорошо но нужно еще узнать КАК инициировать изменение в другом сеансе планирования. Копаюсь в BSP Приложении Tunguska, думаю может обойтись не абапом а джавой.

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



Едва ли. Java тут вообще не при чем, а javascript-ом вы запись в таблицу не вставите.

Нет. а как же блокировка на изменение, отправка е-мэйла и проч хрень? я протрассировал выполннение "запуска на утверждение" - помимо Insert in UPS_CHANGELOG - там еще кода на 6 страниц выполняется.



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

Вы немного протрассировали, а мне пришлось в свое время дописывать почти половину STS, и вы будете мне еще рассказывать как она работает ?

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



Вы написали полную чушь. Почитайте хотя бы немного о том, что такое BSP, Java, Javascript, потом продолжим разговор.

А если на разных компонентах плана установлены иерархии на разных признаках, то как быть с изменением статуса у "нужного" узла? Первый признак является атрибутом второго, но в UPS_CHANGELOG привязки компонента к иерархии не видно.

Все привязки в таблице UPS_HASH