MakionDocs ← makion.dev

CDS, RAP, Fiori e migração

Estas são as funções de construção e migração do produto Development. As funções de construção (CDS, RAP, Fiori) criam e ativam objetos, trabalhando de baixo para cima ao longo da cadeia de dependências. As funções de migração dividem-se por intenção: Migração remedeia interativamente um objeto, enquanto Mapa de migração e Verificação de clean-core são análises de apenas leitura que nada alteram.

Vivem sob o produto Development no compositor do Chat; Mapa de migração e Verificação de clean-core também aparecem sob Consulting. Para o modelo de permissões por detrás de cada função, consulte Como funcionam as funções.

Numa vista geral#

Função Leitura/Escrita Use-a para…
CDS Escrita Construir modelos de dados VDM CDS reais de baixo para cima.
RAP Escrita Construir um objeto de negócio RAP completo.
Fiori Escrita Tornar um serviço OData pronto para Fiori Elements.
Migração Escrita Preparar interativamente um objeto para ECC→S/4 / Clean-Core.
Mapa de migração Apenas leitura Analisar um parque de código personalizado para planeamento S/4.
Verificação de clean-core Apenas leitura Auditar objetos quanto à conformidade com o clean-core.

CDS#

Leitura/Escrita: Escrita.

O CDS desenha e constrói modelos de dados VDM CDS reais — objetos DDLS, DDLX e DCLS mais as suas tabelas. Segue a estratificação do Virtual Data Model: vistas de interface base ZI_ e vistas ZR_, vistas de texto, projeções de consumo ZC_ e controlos de acesso. Constrói de baixo para cima e ativa à medida que avança.

Nunca executa o ABAP cleaner sobre CDS — o DDL do CDS é normalizado pela própria função, não pelo cleaner.

Quando usá-la: para levantar um modelo de dados CDS devidamente estratificado, em vez de uma vista pontual.

RAP#

Leitura/Escrita: Escrita.

O RAP constrói um objeto de negócio RAP completo de ponta a ponta: a table, o DDLS (definição de dados), o DDLX (extensão de metadados), o BDEF (definição de comportamento), a CLAS (implementação de comportamento), o SRVD (definição de serviço) e o SRVB (vinculação de serviço). A sua metodologia é modelo de dados → comportamento (managed) → projeção + serviço → verificar via EML.

A publicação do serviço OData é um passo humano — a função constrói e vincula, mas a publicação é sua.

Quando usá-la: para construir um objeto RAP transacional (cenário managed) a partir de um modelo de dados até um serviço verificado.

Fiori#

Leitura/Escrita: Escrita.

O Fiori torna um serviço OData existente pronto para Fiori Elements. Cria a camada de anotações @UI — extensões de metadados ou @UI inline — mais anotações de value help, texto e pesquisa, e expõe o resultado via SRVD + SRVB.

O deploy do app-shell UI5 e a configuração do launchpad são transferências manuais explícitas — a função prepara o serviço e as anotações; você faz o deploy da aplicação e configura o launchpad.

Quando usá-la: para transformar um serviço OData funcional num que uma aplicação Fiori Elements consiga renderizar, sem escrever anotações à mão.

Migração#

Leitura/Escrita: Escrita.

A Migração é a preparação interativa ECC→S/4HANA / Clean-Core de um objeto (ou de um pequeno pacote). A sua metodologia é avaliar (uma variante ATC de prontidão para S/4 ou uma análise do código-fonte) → remediar constatação a constatação (uma correção mínima, no sentido do clean-core, assinalando armadilhas) → verificarrelatar. Um humano aprova cada alteração.

Quando usá-la: para remediar de facto um objeto específico para S/4, uma constatação de cada vez, com um humano no processo em cada edição.

Mapa de migração#

Leitura/Escrita: Apenas leitura.

O Mapa de migração é a análise do parque de código personalizado (Z/Y) para o planeamento ECC→S/4. Recebe uma exportação USAGE de produção e lê a estrutura de código DEV, calcula o fecho de alcançabilidade a partir dos pontos de entrada utilizados, e classifica cada objeto em USED / REACHABLE / REVIEW / CANDIDATE, cada um com evidência de suporte. Entrega um CSV / relatório.

Nunca toca em produção, e nunca declara código como "morto" ou "seguro para eliminar" — os baldes REVIEW e CANDIDATE são dados de decisão para um humano, não veredictos.

Quando usá-la: para dimensionar e priorizar um parque de código personalizado antes de uma migração para S/4, com evidência para cada classificação.

O Mapa de migração está disponível tanto no produto Development como no Consulting, para que possa alimentar um esforço de construção ou uma entrega de consultoria.

Verificação de clean-core#

Leitura/Escrita: Apenas leitura.

A Verificação de clean-core audita objeto(s) quanto à conformidade com o clean-core do S/4HANA. Procura leituras diretas de tabelas standard, chamadas a APIs não libertadas, modificações, sintaxe obsoleta e contornos de interface, e agrupa cada objeto como COMPLIANT / EXTENSIBLE-VIA-RELEASED / NEEDS-REWORK / BLOCKER. Nada altera.

Quando usá-la: para verificar se objetos específicos estão prontos para o clean-core, e para ver exatamente o que se coloca no caminho.

A Verificação de clean-core está disponível tanto no produto Development como no Consulting.