Form Entry Object Page

Uma form entry object page é adequada quando a tarefa inteira consiste em inserir dados de um único objeto novo e os usuários não têm nada para pesquisar antes: um formulário de solicitação, um cadastro, uma requisição de compra simples aberta a partir de um tile.

Critérios de decisão:

• Nenhuma lista necessária e nenhum contexto para revisar antes de digitar: uma form entry object page.
• O objeto precisa de um status, de dados-chave ou de itens relacionados à vista: uma object page padrão.
• Os usuários pesquisam e depois criam ou editam um entre muitos objetos: um list report com uma object page.
• Apenas dois ou três campos: a criação por diálogo a partir de um list report é mais leve.

Exemplo: um funcionário da Alder Manufacturing abre um tile "Create Purchase Requisition", cai diretamente em um formulário vazio, informa doze cadeiras de escritório da Cedar Office Supply e escolhe Create. Uma form entry object page é a escolha certa quando o app é o formulário.

Uma form entry object page tem três regiões:

1. Título da página: identifica o que está sendo criado, como uma nova requisição de compra.
2. Seções do formulário: as seções e os field groups definidos em UI.Facets, empilhados em uma única página.
3. Barra de rodapé: as ações que salvam ou descartam o novo objeto, além do acesso às mensagens de validação.

O que falta é proposital: sem header facets com dados-chave, sem imagem, sem anchor bar ou barra de abas entre as seções. Como a página mostra o mesmo conteúdo de uma object page padrão, uma seção que funciona em uma também funciona na outra. Uma form entry object page é uma object page reduzida ao formulário e à decisão de salvá-lo.

No SAP Fiori elements para OData V4, três configurações transformam uma object page em uma form entry page:

1. Configurações do target no manifest.json: o target usa o template de object page, com content.header.visible e content.header.anchorBarVisible definidos como false e o conteúdo do cabeçalho não editável.
2. Modo de criação na inicialização: o app component retorna um modo preferencial de criação (create) a partir de seus parâmetros de inicialização, de modo que o app abre um objeto vazio em vez de aguardar uma seleção.
3. Um draft por vez (opcional): a configuração no nível do app singleDraftForCreate faz o app reabrir o draft não salvo do usuário em vez de criar outro.

As anotações não mudam: UI.Facets, UI.FieldGroup e UI.Identification definem o formulário exatamente como em uma object page padrão. A SAP documenta o padrão apenas para o SAP Fiori elements para OData V4. Trata-se de uma propriedade do app, não do sistema; por isso, funciona da mesma forma no SAP S/4HANA e no SAP BTP onde quer que rode uma release do SAPUI5 que suporte essas configurações; verifique o SAPUI5 SDK da sua versão. Configurar uma form entry object page é, portanto, uma decisão de configuração de página, e não uma tarefa de modelagem.

1. Esquecer o modo de inicialização. Sem a preferência de criação, o app não abre em modo de criação, e os usuários não têm uma forma óbvia de começar.
2. Acumular drafts. Cada início abandonado pode deixar um draft; singleDraftForCreate reabre o draft existente em vez disso.
3. Formulários longos sem navegação. Com a anchor bar oculta, um formulário de dez seções vira uma longa rolagem; divida o objeto ou use uma object page padrão com abas.
4. Editar objetos existentes em uma form entry page. Sem cabeçalho, os usuários perdem o status e os dados-chave de que precisam ao alterar dados.

Quando o app abre em modo de exibição ou vazio em vez de em modo de criação, verifique os parâmetros de inicialização no Component.js, depois se o primeiro target é o template de object page e, por fim, as configurações de draft do serviço. A maioria dos problemas de form entry object page são problemas de configuração de inicialização, e não de anotação.