Адаптация ABAP после перехода: данные, API и финансовая семантика

После анализа кода нужен не массовый «рефакторинг под HANA», а контролируемое исправление тех объектов, которые затрагивает выбранный source-to-target переход. Исправление считается принятым, когда оно соответствует целевому release, сохраняет ожидаемый результат финансовой операции и прошло проверку в целевом окружении.

Превратите finding в конкретное требование#

Для каждого ATC finding, Simplification Item или ошибки после конверсии определите:

исходную и целевую версию и используемый check variant;
изменившийся SAP-объект, интерфейс, структуру или ограничение и ссылку на SAP Note;
точный Z-объект и путь исполнения, который зависит от изменения;
тип действия: синтаксис/типизация, изменение доступа к данным, переход на поддерживаемый API, исправление производительности или redesign;
финансовый процесс, пользователя, данные и контроль, которые должны остаться неизменными.

Проверьте сообщение по документации конкретной target-версии и примечанию, на которое оно ссылается. Quick fix может уменьшить технический finding, но не решает вопрос бизнес-семантики, роли авторизации или полноты сценария. Применяйте автоматическое исправление как кандидата в code review; после него активируйте объект, повторите ATC и проверьте diff.

Проверяйте смысл изменённых объектов и API#

Не предполагайте, что таблица с тем же названием или compatibility view сохраняет прежнюю структуру, гранулярность и поддержку всех полей. Для каждого прямого доступа определите, какие поля, ключи, суммы, ledger и фильтры реально использует приложение. Сопоставьте их с целевым объектом, совместимостью, ограничениями чтения/записи и целевым контрактом.

Compatibility view может предоставлять ограниченную совместимость для прежнего интерфейса; это не универсальный договор на дальнейшую разработку и не разрешение изменять представленные данные через него. Сверьте назначение и срок поддержки для target release. Для новых чтений выбирайте документированный CDS View из подходящей области VDM и учитывайте его stability contract, статус, авторизации и пригодность для нужного сценария.

View Browser и документация помогают исследовать поля, семантические аннотации, назначение, статус и возможного successor. Выбор successor требует сравнить, что именно возвращает новый объект и какие фильтры/измерения он поддерживает. Одинаковый label у поля не доказывает эквивалентность.

Для финансовой операции сохраняйте необходимые измерения: company code, ledger, account assignment, currency, fiscal period, posting/document date и document/line identity. Не переходите на агрегатный CDS-запрос, если потребителю нужны открытые позиции, сторно, отдельные строки или lineage до исходного документа.

Сохраняйте семантику в изменениях типов и SQL#

Проверьте длину и тип каждого значения на границах SAP API, структуры, внутренней таблицы и внешнего интерфейса. Усечение identifier или сумма с прежней точностью могут не вызывать синтаксическую ошибку, но приводить к неверному поиску объекта, отбрасыванию строк или изменению суммы. Сопоставьте типы, преобразования, округление, null/initial и сортировку на реальных граничных примерах.

Для SQL-переписывания установите, какой результат требует процесс: полный набор строк, точные ключи, понятный порядок, дедупликация или агрегирование. Не полагайтесь на случайный порядок строк без явной сортировки. Проверьте joins, клиентские ограничения, единицы/валюты, фильтры периода и различия между источником и CDS-слоем. Статически корректный SELECT не гарантирует тот же набор бухгалтерских документов.

Если чтение участвует в финансовом расчёте, проверьте currency/amount pair, валюту оценки, ledger, posting date и правила периода. Если читает интерфейс, проверьте его contract и downstream consumers. Изменение доступа к данным не должно незаметно менять формулу, выборку или детализацию.

Измеряйте производительность на критическом пути#

После замены структуры или SQL зафиксируйте прежний и целевой запрос, системные/периодные параметры, объём данных и число результатов. Измеряйте representative execution для фактического процесса на целевой платформе. Сравните runtime, число прочитанных строк, объём переданных данных, количество обращений и memory use там, где доступны эти метрики.

Не оптимизируйте по одному тесту с пустой базой. Проверьте массовую обработку, крупный период, типичные фильтры, редкий длинный документ и межсистемный поток, если они входят в scope. HANA execution plan может отличаться от прежней базы; переписывание должно подтвердить улучшение без потери смысла и корректности.

Стройте исправление вместе с финансовым тестом#

Для каждой адаптации свяжите finding, commit/transport, целевой SAP объект/API, ожидаемый вход и результат, финансовую сверку и regression owner. Используйте малые изменения, которые можно проверить отдельно; массовый quick fix без изолируемого результата затрудняет диагностику.

В минимальном regression-наборе для затронутого объекта проверьте:

обычную и граничную запись, включая длинные ключи, нулевые значения и большие суммы;
несколько валют, ledger, дату документа и дату проводки, включая границу открытого/закрытого периода;
несколько строк документа, сторно, повторную обработку и open/cleared status, если они поддерживаются сценарием;
авторизацию, company/client scope и внешние интерфейсы, которые используют результат;
контрольные суммы, количества документов и трассировку результата к исходной записи;
ATC на целевом варианте и измерение критического performance path после адаптации.

Сравнивайте исходную и исправленную реализацию на одном входном снимке. Каждое допустимое отличие должно быть описано как ожидаемое изменение SAP, а не просто принято из-за нового кода. После конверсии повторите target checks и бизнес-регрессию на фактическом релизе.

Не объединяйте в одну задачу устранение syntax error, замену API, оптимизацию SQL и пересмотр бизнес-правила. Если процесс должен намеренно поменяться, согласуйте его отдельно с владельцем учёта и задайте новую ожидаемую сверку.

Этот материал частично покрывает MIG-09. Руководства Custom Code Migration для S/4HANA 2025 относятся к On-Premise и Private Edition; источники по compatibility views, VDM и View Browser относятся к On-Premise 2025 FPS01. Реальный ABAP код, ATC run, API scope, производительность, финансовые данные и SAP runtime не проверялись; источники остаются metadata_only.

Связанные материалы#

After custom-code analysis, the work is not a broad "HANA refactoring". It is a controlled correction of objects affected by the selected source-to-target transition. A fix is accepted when it complies with the target release, preserves the expected result of the finance operation, and has been checked in the target environment.

Turn a finding into a concrete requirement#

For each ATC finding, Simplification Item, or post-conversion error, record:

source and target versions and the check variant in use;
the changed SAP object, interface, structure, or limitation and its SAP Note;
the exact custom object and execution path that depends on the change;
action type: syntax/typing, data access, supported API change, performance correction, or redesign;
finance process, users, data, and control that must remain unchanged.

Interpret the message using documentation and the note for the target version. A quick fix may resolve a technical finding, but does not answer business semantics, authorization, or scenario completeness. Treat an automated correction as a code-review candidate; activate the object, rerun ATC, and review the diff afterward.

Check the meaning of changed objects and APIs#

Do not assume that a table with the same name or a compatibility view retains the old structure, grain, and support for every field. For each direct access, determine which fields, keys, amounts, ledgers, and filters the application actually uses. Map them to the target object, compatibility behavior, read/write boundary, and supported contract.

A compatibility view can provide limited compatibility for a former interface; it is not a universal contract for new development or permission to modify data through the view. Check its purpose and support lifetime for the target release. For new reads, choose a documented CDS view from the appropriate VDM area and verify its stability contract, status, authorizations, and fitness for the scenario.

View Browser and the documentation can help inspect fields, semantic annotations, purpose, status, and possible successors. Selecting a successor requires comparing the data it returns and the filters/dimensions it supports. A matching field label does not prove equivalence.

For finance, preserve necessary dimensions: company code, ledger, account assignment, currency, fiscal period, posting/document date, and document/line identity. Do not replace detail with an aggregate CDS query when consumers require open items, reversals, individual lines, or lineage to the source document.

Preserve semantics when changing types and SQL#

Check the length and type of every value crossing SAP API, structure, internal-table, and external-interface boundaries. A truncated identifier or an amount with obsolete precision may not cause a syntax error, but can select the wrong object, drop rows, or change an amount. Compare types, conversions, rounding, null/initial handling, and sorting on real boundary cases.

For an SQL rewrite, establish what the process requires: full row set, exact keys, defined ordering, de-duplication, or aggregation. Do not rely on accidental row order without explicit sorting. Check joins, client restrictions, units/currencies, period filters, and differences between the source and CDS layer. A syntactically valid SELECT does not guarantee the same accounting documents.

If a read participates in a financial calculation, verify the currency/amount pair, valuation currency, ledger, posting date, and period rules. If it feeds an interface, verify its contract and downstream consumers. A data-access change must not silently change the formula, selection, or level of detail.

Measure performance on the critical path#

After changing a structure or query, record the old and target query, system and period parameters, data volume, and number of results. Measure representative execution for the actual process on the target platform. Compare runtime, rows read, data volume transferred, number of database calls, and memory use where those metrics are available.

Do not optimize from one test on an empty database. Check mass processing, a large period, typical filters, a rare long document, and an inter-system flow if in scope. HANA execution plans may differ from the former database; a rewrite must prove improvement without losing meaning or correctness.

Build the change together with a finance test#

For each adaptation, link the finding, commit/transport, target SAP object or API, expected input and result, finance reconciliation, and regression owner. Use small changes that can be checked independently; a bulk quick fix without an isolated result makes diagnosis harder.

For affected objects, include a regression set for:

a normal and boundary record, including long keys, zero values, and large amounts;
multiple currencies, ledger, document date and posting date, including open/closed-period boundaries;
multi-line documents, reversals, reprocessing, and open/cleared status where the scenario supports them;
authorization, company/client scope, and external interfaces consuming the result;
control totals, document counts, and traceability to the source record;
ATC on the target variant and measurement of the critical performance path after adaptation.

Compare the old and corrected implementation using the same snapshot. Describe every accepted difference as an expected SAP change rather than accepting it because code changed. After conversion, repeat target checks and business regression on the actual release.

Do not combine a syntax fix, API replacement, SQL optimization, and business-rule review in one task. If the process is meant to change, agree that separately with the accounting owner and define a new expected reconciliation.

This partially covers MIG-09. Custom Code Migration Guides refer to SAP S/4HANA 2025 for On-Premise and Private Edition; compatibility-view, VDM, and View Browser sources refer to On-Premise 2025 FPS01. Customer ABAP code, ATC runs, API scope, performance, financial data, and SAP runtime were not checked; sources remain metadata_only.