== SearchService ==
Para se usar o SearchService não é necessário uma validação pois os headers já são definidos automaticamente pela plataforma. Os métodos ”’UrlMap.getModule()”’ e ”’UrlMap.getMenu()”’ fazem justamente essa tarefa de pegar parâmetros de ambiente e aplicativo para fazer a comunicação com o banco de dados.
SearchService.list(“Módulo”, “Menu”, “Entidade”, “Filtros”)
”’Módulo”’ = Refere-se ao módulo que está na navegação atual: Ex: isquik-dev.isquik.com/api/”’SDK”’/PDS/api
”’Menu”’ = Refere-se ao menu que está na navegação atual: Ex: isquik-dev.isquik.com/api/SDK/”’PDS”’/api
”’Entidade”’ = Tabela que será realizada a pesquisa.
”’Filtro”’ = Parâmetros a serem utilizados
Geralmente o SearchService está dentro do RequestManager separado em duas principais funções: list e get.
RequestManager: {
list: (entity, filter) => SearchService.list(UrlMap.getModule(), UrlMap.getMenu(), entity, filter),
get: (entity, id) => SearchService.get(UrlMap.getModule(), UrlMap.getMenu(), entity, id),
exec: (queryName, parameters) => app.services.QueryService.execute(queryName, parameters)
},
O list recebe como parâmetro `entity` e `filter`.
”’Entity”’ é a tabela que se quer fazer a pesquisa.
”’Filter”’ é um objeto JSON com os possíveis filtros a serem usados. O campo ”’filter”’ tem diversas opções de uso, então ele vai ter uma sessão apenas para ele.
Ex:
SearchService.list(UrlMap.getModule(), UrlMap.getMenu(), “Cliente”, { IdCliente: 51 })
O get recebe como parâmetro um `entity` e um `id`
”’Entity”’ é a tabela que se quer fazer a pesquisa.
”’Id”’ é uma ”’string”’ ou ”’int”’ que será a identificação da ”’PK”’ da do entity referente.
Ex:
SearchService.list(UrlMap.getModule(), UrlMap.getMenu(), “Cliente”, 51 )
== Filter ==
O ”’filter”’ é utilizado para, como o nome indica, passar filtros para a pesquisa. Para entender facilmente, ele é o campo WHERE de uma query tradicional. O parâmetro passado é um JSON simples, relativamente similar ao usado pelo MongoDB.
{ IdCliente: 51 }
Podem ter várias opções dentro do filtro
{ IdCliente: 51, IdTipoAtendimento: 8 }
E adicionar filtros mais avançados usando o ”’Comparsion”’ (sim, escrito assim mesmo). O que se pode passar no Comparsion: “=”, “!=”, “>”, “>=”, “<“, “<=”, “IsNull”, “NotNull”, “In”, “NotIn”, “NotLike”, “Like”, “Between”.
”’Importante! Todas as tags são case sensitive!”’
Cada um tem sua própria particularidade. Seguem exemplos feitos na tabela de Atendimento:
{
DataUltimaAlteracao: {
Value: ‘2017-01-01T00:00:00.000’,
Value2: ‘2018-01-01T23:59:59.999’,
Comparsion: ””Between””
}
}
Repare que você tem que ter um campo ”’Value”’
{
DataExclusao: {
Comparsion: ”’‘IsNull””,
Value: “DataExclusao”
}
}
Em alguns casos o ”’Value”’ também pode ser um ”’array”’
{
DataExclusao: {
Comparsion: ””In””,
Value: [1493, 1503]
}
}
== Return ==
O return é utilizado para configurar os retornos dos dados. Ele tem 5 principais filtros: ”’Columns”’, ”’Relashionship”’, ”’Configuration”’, ”’Distinct”’ e ”’Multiples”’. Você pode passar o return como parâmetro nos headers pelo postman, por exemplo.
”’Columns”’
Nele você pode passar um array de campos que retornarão da requisição
{ “Columns”: [“Id”, “Nome”] }
”’Relashionship”’
Indica se trará algum relacionamento* na consulta. O valor padrão é ”’true”’
{ “Relashionship”: false }
”’Configuration”’
Indica se trará os dados de configuração da tabela que está sendo consultado. O valor padrão é ”’true”’
{ “Configuration”: false }
”’Distinct”’
Trabalha em conjunto com ”’Columns”’. O valor padrão é ”’false”’
{ “Distinct”: true }
”’Multiples””
Utilizado para poder fazer N consultas em apenas uma requisição, além da requisição principal. Se utilizado, a estrutura do return pode ser repetido dentro dessa.
Deve-se utilizar a propriedade Table para identificar qual tabela está sendo consultada
{
“Multiples”: [
{
“Table”: “Cliente”,
“Columns”: [“Id”, “Nome”],
“Configuration”: false,
“Relashionship”: false
},
{
“Table”: “Recurso”,
“Columns”: [“Id”, “Nome”],
“Configuration”: false,
“Relashionship”: false
}
]
}
Aqui um exemplo completo buscando a tabela ”’Atendimento”’, retornando apenas os campos necessários e junto outras tabelas para composição da tela:
{
“filter”: { “IdCiente”: 81 },
“return”: {
“Columns”: [“IdAtendimento”, “Resumo”, “DataAbertura”],
“Configuration”: false,
“Relashionship”: false,
“Multiples”: [
{
“Table”: “Cliente”,
“Columns”: [“IdCliente”, “Nome”],
“Configuration”: false,
“Relashionship”: false
},
{
“Table”: “StatusAtendimento”,
“Columns”: [“IdStatusAtendimento”, “Descricao”],
“Configuration”: false,
“Relashionship”: false
},
{
“Table”: “TipoAtendimento”,
“Columns”: [“IdTipoAtendimento”, “Descricao”],
“Configuration”: false,
“Relashionship”: false
}
]
}
}
* Dentro do PDS, no Dicionário de Dados, é possível editar as tabelas e adicionar relacionamentos a elas, tanto para tabelas “filhas” quanto para tabelas “pais”. Esses são os relacionamentos a que se refere essa opção
== Postman ==
Para teste ou uso no Postman, você pode, por exemplo, testar na URL https://isquik-dev.isquik.com/api/SDK/PDS/api/”'{{Tabela}}”’. Passar nos headers a tag authorization com o token do Bearer.
Para se conseguir esse Bearer, basta logar no IsQuik, abrir o inspetor de código na aba Network e atualizar a página. Olhando nos registros da requisição você consegue encontrar o authorization
Você pode entender mais sobre o postman aqui: https://medium.com/trainingcenter/indo-al%C3%A9m-com-postman-3f95726e0bb4