Este serviço oferece uma interface geral para declarações personalizadas, onde essas declarações são representadas usando o esquema de declarações WCO. Além de enviar declarações, o serviço de Declarações Aduaneiras permite alterá-las e cancelá-las. Ele também oferece a capacidade de fazer upload de documentos comprovativos e fazer notificações de chegada.
O objetivo da API do Serviço de Declarações Aduaneiras é:
Como o processo de notificação é assíncrono, a única resposta desta API ao declarante é indicar o sucesso (ou não) da validação e envio ao backend do CDS.
sbt run
que é executado na porta 9820
por padrãosbt 'run -Dapplication.router=testOnlyDoNotUseInAppConf.Routes'
O serviço de Declarações Aduaneiras pode ser executado localmente no Service Manager, usando os seguintes perfis:
Detalhes do perfil | Comando | Descrição |
---|---|---|
CUSTOMS_DECLARATION_ALL | sm2 --start CUSTOMS_DECLARATION_ALL | Para executar todos os aplicativos CDS. |
CUSTOMS_INVENTORY_LINKING_EXPORTS_ALL | sm2 --start CUSTOMS_INVENTORY_LINKING_EXPORTS_ALL | Para executar todos os aplicativos relacionados às exportações de vinculação de inventário CDS. |
CUSTOMS_INVENTORY_LINKING_IMPORTS_ALL | sm2 --start CUSTOMS_INVENTORY_LINKING_IMPORTS_ALL | Para executar todos os aplicativos relacionados às importações de vinculação de inventário CDS. |
sbt test
sbt IntegrationTest/test
sbt test IntegrationTest/test
./run_all_tests.sh
clean scalastyle coverage test it:test coverageReport dependencyUpdates"
Para executar os testes de aceitação do CDS, veja aqui.
Para executar testes de desempenho, veja aqui.
Para documentação da API de declarações alfandegárias, veja aqui.
Caminho - rotas internas prefixadas por /customs-declarations | Métodos Suportados | Descrição |
---|---|---|
/customs-declarations/ | PUBLICAR | Endpoint para enviar uma declaração. |
/customs-declarations/cancellation-requests | PUBLICAR | Endpoint para cancelar uma declaração. |
/customs-declarations/amend | PUBLICAR | Endpoint para alterar uma declaração. |
/customs-declarations/file-upload | PUBLICAR | Endpoint para enviar um upload de arquivo. |
/customs-declarations/uploaded-file-upscan-notifications/clientSubscriptionId/:clientSubscriptionId | PUBLICAR | Endpoint para gerenciar notificações de upscan de upload de arquivos. |
/customs-declarations/file-transmission-notify/clientSubscriptionId/:clientSubscriptionId | PUBLICAR | Endpoint para enviar notificações de upload de arquivos para notificação alfandegária. |
/customs-declarations/arrival-notification | PUBLICAR | Endpoint para enviar uma declaração de notificação de chegada. |
Caminho | Métodos Suportados | Descrição |
---|---|---|
/file-upload/test-only/all | EXCLUIR | Endpoint para excluir todos os metadados de upload de arquivo. |
Uma solicitação para o endpoint /file-upload pode conter URLs SuccessRedirect e errorRedirect. Estes não são obrigatórios. Se um redirecionamento de sucesso e de erro estiver incluído, o upscan v2 será chamado, caso contrário, v1.
link para comandos curl
Existe uma tarefa SBT zipWcoXsds
que gera um arquivo ZIP contendo esquemas e mensagens de exemplo para cada versão em /public/api/conf
durante a fase de empacotamento (portanto, não são geradas durante o desenvolvimento normal). Esses arquivos ZIP são referenciados pelo YAML. Essas referências são renderizadas como links HTML para o ZIP gerado no serviço implementado.
Para gerar o arquivo zip localmente, execute o seguinte comando na linha de comando do diretório raiz do projeto:
sbt package
fieldsId
do serviço api-subscription-fields
O cabeçalho X-Client-ID
, junto com o contexto e a versão do aplicativo, são usados para chamar o serviço api-subscription-fields
para obter o UUID fieldsId
exclusivo para passar para a solicitação de back-end.
Observe que o serviço para obter o fieldsId
não está atualmente em stub.
api-subscription-fields
para testes locais ponta a ponta Certifique-se de que o serviço api-subscription-fields
esteja em execução na porta 9650
. Em seguida, execute o comando curl abaixo.
Observe que a versão 2.0
é usada como exemplo nos comandos dados, e você deve inserir o número da versão da API das declarações aduaneiras que você chamará posteriormente.
Observe que o valor d65f2252-9fcf-4f04-9445-5971021226bb
é usado como exemplo nos comandos fornecidos, e você deve inserir o valor UUID que atenda às suas necessidades.
curl -v -X PUT "http://localhost:9650/field/application/d65f2252-9fcf-4f04-9445-5971021226bb/context/customs%2Fdeclarations/version/2.0" -H "Cache-Control: no-cache" -H "Content-Type: application/json" -d '{ "fields" : { "callbackUrl" : "https://postman-echo.com/post", "securityToken" : "securityToken", "authenticatedEori": "ABC123" } }'
Em seguida, temos que redefinir manualmente o campo fieldId
para corresponder ao ID esperado pelos serviços downstream. Em uma janela de comando do mongo, cole o seguinte, um após o outro.
use api-subscription-fields
db.subscriptionFields.update(
{ "clientId" : "d65f2252-9fcf-4f04-9445-5971021226bb", "apiContext" : "customs/declarations", "apiVersion" : "2.0" },
{ $set:
{"fieldsId" : "d65f2252-9fcf-4f04-9445-5971021226bb"}
}
)
Ao enviar uma solicitação para customs-declarations
certifique-se de ter o cabeçalho HTTP X-Client-ID
com o valor d65f2252-9fcf-4f04-9445-5971021226bb
Três versões deste serviço estão disponíveis no Developer Hub.
Cada um tem seções de configuração separadas para o endpoint de declaração wco do MDG para que as versões possam ser apontadas para diferentes serviços de back-end.
Fornecer o cabeçalho ACCEPT necessário na solicitação distingue qual configuração de serviço usar:
Aceitar cabeçalho | Versão |
---|---|
aplicativo/vnd.hmrc.1.0+xml | v1 |
aplicativo/vnd.hmrc.2.0+xml | v2 |
aplicativo/vnd.hmrc.3.0+xml | v3 |
Observe que as solicitações com qualquer outro valor do cabeçalho Accept
são rejeitadas com o status de resposta 406 Not Acceptable
.
A comutação dinâmica de terminais de serviço foi implementada para o conector de declaração wco. Para configurar a comutação dinâmica do endpoint, deve haver uma seção correspondente no arquivo de configuração do aplicativo (veja o exemplo abaixo). Deve conter os detalhes de configuração do endpoint.
O serviço customs-declarations
possui uma configuração default
e uma configuração stub
. Observe que a configuração default
é declarada diretamente na seção de customs-declarations
.
Prod {
...
services {
...
wco-declaration {
host = some.host
port = 80
bearer-token = "some_token"
context = /services/declarationmanagement/1.0.0
stub {
host = localhost
port = 9479
bearer-token = "some_stub_token"
context = "/registrations/registerwithid/1.0.0"
}
}
v2 {
wco-declaration {
host = some.host
port = 80
bearer-token = "some_token"
context = /services/declarationmanagement/1.0.0
stub {
host = localhost
port = 9479
bearer-token = "some_stub_token"
context = "/registrations/registerwithid/1.0.0"
}
}
}
}
}
default version (application/vnd.hmrc.1.0+xml):
curl -X "POST" http://customs-declarations-host/test-only/service/wco-declaration/configuration -H 'content-type: application/json' -d '{ "environment": "stub" }'
version 2 (application/vnd.hmrc.2.0+xml):
curl -X "POST" http://customs-declarations-host/test-only/service/v2.wco-declaration/configuration -H 'content-type: application/json' -d '{ "environment": "stub" }'
The service customs-declarations is now configured to use the stub environment
curl -X "POST" http://customs-declarations-host/test-only/service/wco-declaration/configuration -H 'content-type: application/json' -d '{ "environment": "default" }'
The service customs-declarations is now configured to use the default environment
curl -X "GET" http://customs-declarations-host/test-only/service/wco-declaration/configuration
{
"service": "wco-declaration",
"environment": "stub",
"url": "http://currenturl/customs-declarations"
"bearerToken": "current token"
}
Este código é um software de código aberto licenciado sob a licença Apache 2.0.