Возникла необходимость в существующем BSP приложении в заголовок каждой страницы добавить некое содержимое. Не ленивый программист открыл бы каждую страницу и добавил руками. Но такой лентяй как я решил, что это не круто и решил найти способ поменять результирующий HTML, отдаваемый BSP приложением.
Вначале была идея написать свой HTTP Request Handler и встроить его в систему. Но выяснились следующие вещи. Во-первых, просто присвоить свой обработчик в транзакции SICF к своему Z-BSP-приложению не получится, потому что все Z-BSP-приложения находятся на уровне /default_host/sap/bc/bsp/sap/*, а на раздел BSP уже назначен обработчик CL_HTTP_EXT_BSP, и все обработчике ниже этого узла работать не будут. Можно бы было добавить свой обработчик к узлу /default_host/sap/bc/bsp/, либо вообще его заменить своим, из которого уже вызывать изначальный. Но как показывает чужой опыт (вот, например) это может привести к тому, что сервис будет деактивирован после переноса запроса в целевую систему. Хотя его потом можно активировать вручную, хотелось бы избежать лишних телодвижений и дерганья базисников. И это - во-вторых.
Тогда был найден другой способ. Каждому BSP приложению можно назначить Класс приложения на вкладке Свойства. Этому классу (либо его родительскому классу) можно назначить интерфейс IF_BSP_APPLICATION_EVENTS и реализовать его. Реализовать нужно 4 метода (ON_REQUEST, ON_RESPONSE, ON_START и ON_STOP). Причем реализация может быть пустой - главное чтобы метод был.
Методы ON_START и ON_STOP вызываются при запуске и завершении всего BSP-приложения. Методы ON_REQUEST и ON_RESPONSE вызываются для каждого запроса, перед и после стандартного обработчика, соответственно.
В моем случае мне подходил ON_RESPONSE, так как мне нужно было менять готовый ответ. Текущую отдаваемую страницу можно было получить с помощью RESPONSE->GET_CDATA( ), а установить новую с помощью RESPONSE->SET_CDATA(), где RESPONSE - параметр метода ON_RESPONSE типа IF_HTTP_RESPONSE.
