por ·0 comentários

Em dezembro de 2017 separei um notebook que não estava mais usando e tomei o caminho de instalar um linux para avaliar o quando seria possível viver sem Windows e sem uma máquina virtual (rsrs).
Como todos sabem, a principal ferramenta de trabalho que utilizo é o Delphi – então o desafio ficou imenso – já que sem uma máquina virtual e sem o windows é impossível utilizar o Delphi. Usando outro framework para substituir o Delphi não iria proporcionar emoção – então descartado frameworks na mesma linha.
Primeiro ponto, o que usar para desenvolver aplicativos ? Como bom delpheiro JAVA não estava nos meus planos, queria algo mais novo.

Primeira parada – se atualizar
Desktop, WEB, Mobile – são opções de plataforma de trabalho. Estacionei no item WEB, vamos procurar o que temos para explorar aí.
Já havia utilizado o Angular-JS a alguns anos para implementar algumas coisas, então vamos nos atualizar no que há de mais novo de Angular – Angular 5 (logo no início do ano veio o 6), tudo novo – esquece o Angular-JS – agora é Typescript.
Typescript é uma implementação feito utilizando como base o javascript – você escreve Typescript e o compilador gera código javascript para ser utilizada no Browser – nem tudo precisa iniciar do zero – legal.

No AngularIO, novas ferramentas de geração e compilação vieram no pacote:

  • o NG (a ferramento do AngularIO) agora gera compilações para serem publicadas no servidor do SITE
  • compila para teste local na máquina com um mecanismo de “Hot Load” muito eficiente – ficou muito bom
  • é muito produtivo para criação de páginas dinâmicas
  • com uso de NodeJS é possível escrever servidores para publicar serviços (ex: busca em banco de dados)

Ferramentas
Para trabalhar com AngularIO, não é preciso ter um windows rodando – Assim como no windows, no linux temos disponível o VS – Virtual Code Studio da MS que faz o trabalho com perfeição, primeira etapa concluída – já é possível seguir o trabalho diário sem Windows.

Preparação de Infra-estrutura
Primeiro passo a resolver é fazer a integração do código Typescript para consumir os serviços de REST em produção escritos em DELPHI. Para isto utilizei o ODataBr (parte do pacote MVCBr – vários artigos aqui no blog – MVCBr).

  • Criado uma camada base de comunicação com o servidor – a parte de http, autenticação, tradução de protocolo, tratamento de “Future” ou respostas assíncronas
  • Criado camada de comandos com classe que tenham regrar de tratamento do protocolo OData
  • Criado camada de classes de acesso aos serviços do servidor utilizados pela aplicação

Produtos com AngularIO

  • Criado um Dashboard para os aplicativos Delphi que estavam em fase de produção para lançamento em 2018
  • Treinamento de equipe para desenvolvimento em AngularIO
  • Implementação da plataforma NcConstruir – com portal de interação do logista com a plataforma – ver: Nc Construir
  • Implementado uma experiência de venda de produto por Mobile rodando em WebView;

Segunda parada – Google Firebase
…. próximo

por ·0 comentários

A versão 2 do ODataBr (antigo MVCBrODataServer) recebeu novos recursos de melhoria de performance e outros de funcionalidades como segue.

1. Melhorias
– algumas propriedades do FireDAC foram alteradas visando a melhoria de performace – alterações de propriedades;

2. Correções
– Foi feito correção para tabelas JOIN

exemplo: http://localhost:8080/OData/OData.svc/cliente(1)/vendas

no exemplo é feito um JOIN entre os dados do cliente=1 e a tabela de vendas para mostrar as vendas do daquele cliente;

3. Recursos novos

– Adicionado na pasta ./bin/admin o front-end de acesso administrativo para acesso: http://localhost:8080/admin
– Nas instruções PATCH de atualização dos dados no servidor, acrescentado a opção “rowstate”: “modifyORinsert” – tenta fazer um update, caso não encontre nenhum registro então tenta um INSERT;
com isto a propriedade “rowstate” passou a ter as seguintes opções: inserted, updated, modified e modifyORinsert
– proxy para gerar código TypeScript nativo fazendo a chamada: http://localhost:8080/OData/hello/ng irá retornar um código typescript/angular para acesso ao metadata utilizado no servidor;

exemplo: http://localhost:8080/OData/hello/ng
[code]

/// <summary>
/// ODataBr – Generate NG5 Script
/// Date: 17/01/2018 22:39:46
/// Auth: amarildo lacerda – tireideletra.com.br
/// gerado pelo Servidor ODataBr: …/OData/hello/ng
/// </summary>

import { Injectable, Inject } from ‘@angular/core’;
import { HttpClient, HttpHeaders } from ‘@angular/common/http’;
import { ODataProviderService,ODataFactory,ODataService } from ‘./odata-provider.service’;
import { Observable } from ‘rxjs/Rx’;

export interface ODataBrQuery extends ODataService{}

@Injectable()
export class ODataBrProvider {
token:string="";
urlBase:string="";
urlPort:number = 8080;
headers: HttpHeaders;

port(aPort:number):ODataBrProvider{
this.urlPort = aPort;
return this;
}
url(aUrl:string):ODataBrProvider{
this.urlBase = aUrl;
return this;
}

getJson(url:string):Observable<any>{
this.configOptions();
return this._odata.getJson(url);
}
getOData(query:ODataService):ODataProviderService{
this.configOptions();
return this._odata.getValue(query);
}
private configOptions(){
if (this.token!="") { this._odata.token = this.token; };
this._odata.createUrlBase(this.urlBase,this.urlPort);
if (this.headers.keys().length>0) {
//this._odata.headers.clear;
for(let item of this.headers.keys() ){
this._odata.headers.set(item,this.headers.get(item));
}
}
}

constructor(private _odata:ODataProviderService ) {
this.headers = new HttpHeaders();
}
get_filial( query:ODataBrQuery ):ODataProviderService {
this.configOptions();
query.resource = "filial"+(query.join?query.join:"");
return this._odata.getValue( query );
}

get_produtos( query:ODataBrQuery ):ODataProviderService {
this.configOptions();
query.resource = "produtos"+(query.join?query.join:"");
return this._odata.getValue( query );
}
…
}

[/code]

– Adicionado classe base em Typescript/Angular para acesso o servidor OData com a estrutura fundamental de acesso aos dados
Classe typescript/angular para acesso ao servidor

Exemplo de utilização da classe typescript/angular é possível consulta o font-end de “admin” em: http://front-end admin

ver também:
introdução ao oData

por ·1 Comentário

Vou abordar hoje uma das maneira mais fáceis de inserir código malicioso em comando SQL. O título indicando o Firebird é só um direcionamento do teste, mas se aplica praticamente a todos os banco de dados relacional (ou quase todos).

1. Um código Vulnerável

Uma simples janela de “login” pode significar uma entrada a explorar, como veremos.

Em geral uma janela de “login” pede o código/senha de usuário.

Exemplos de “select” para validar o usuário:

Caso 1:

considere o select: ‘select codigo,nome from usuario where codigo=’ +edit1.text+’ and senha=’+edit2.text;

como testar:

  1. digite uma aspas   ‘  no edit1.text e tente entrar; se o resultado for um erro, então você receberá informações sobre o que ocorreu e poderá indicar que o código do aplicativo é vulnerável.
  2. tente digitar no edit1.text:
    ' or 1=1 --

    note que com o select indicado o usuário ganhará acesso ao sistema.

Caso 2:

considere o select:    format(‘select codigo,nome from usuario where codigo=%s and senha=%s,[edit1.text,edit2.text]);

  • tente digitar no edit1.text: 
    ' or 1=1 --

 

2. Como quebrar a vulnerabilidade

Para quebrar a vulnerabilidade, o passo mais seguro é utilizar parâmetros nos “select” ou forçar as aspas por código, vejamos como fazer o correto:

  • ‘select codigo,nome from usuario where codigo=:codigo and senha=:senha’
  • ‘select codigo,nome from usuario where codigo=’+quotedstr(edit1.text)+’ and senha=’+quotedstr(edit2.text);

 

por ·0 comentários

Nestes primeiros meses de 2017, o grupo MVCBr dedicou a maior parte do tempo em implementar um servidor OData que permite o acesso a base de dados utilizando protocolo RESTful via HTTP.

FIREBIRD !!!

Sim….. o servidor OData  implementado no MVCBr é um servidor que expõe recursos (resources) armazenados em um servidor FIREBIRD 3.0

Simplificando, o servidor MVCBrServer é um servidor RESTful que utiliza o protocolo OData que suporta o Firebird3.

Arquitetura do Servidor

O servidor é um servidor implementado utilizando componentes INDY para fazer o processamento das requisições. Ao receber a chamada do CLIENTE o motor INDY passa para o framework  “Delphi MVC Framework” implementado pelo “Daniele Teti”. Seguindo os padrões RESTful, o servidor analisa o tipo de pacote que esta recebendo (GET, PUT, POST, PATCH, DELETE, OPTIONS) e passa a requisição para um PARSER OData implementado no framework MVCBr. Ao receber a requisição o PARSER prepara a requisição que será feito ao banco de dados (ex: select * from produtos), avalia o “metadata” contendo as regras de acesso e constrói a solicitação através da estrutura do FireDAC do Delphi, que remete ao driver o FIREBIRD. Recebendo o retorno tudo é empacotado utilizando JSON e devolvido para o cliente.

 

O “metadata” – Onde o modelo relacional é descrito

Junto com o projeto MVCBr irá encontrar um banco FIREBIRD3  (MVCBr.fdb)  que possui uma estrutura básica de teste utilizada no “framework”

Configurar o “databases.conf” do firebird:

#
# Live Databases:
#
mvcbr=[path]/mvcbr.fdb

Como configurar um resource

Resource é o identificar a ser utilizado no HTTP para acessar um determinado recurso do banco de dados.
Veja o exemplo:

    {
      "resource": "produtos",
      "collection": "produtos",
      "keyID": "codigo",
      "maxpagesize": 100,
      "fields": "*",
      "method": "GET,PATCH,POST,PUT,DELETE",
      "relations": [
        {
          "resource": "grupos",
          "sourceKey": "grupo",
          "targetKey": "codigo",
          "join": "left join grupos on (produtos.grupo=grupos.grupo)"
        }
      ]
    }

  • resource:  apelido para o URL utilizada no HTTP
  • collection: nome da tabela fisica no banco de dados
  • keyID: coluna de acesso rápido ás linhas da tabela    ex: http://…./OData/OData.svc/produtos(‘789112313311’)
  • maxpagesize: número máximo de linhas a retornar caso não seja indicado o comando   $top
  • fields: lista de colunas a retornar quando o comando  $select não for indicado
  • method: quais as permissões serão publicadas aos clientes
  • relations: quais relacionamento podem ser executados com “resource” corrente  ( é um DETAIL)
    • relations.resource: qual o apelido do relacionamento com o resource MASTER
    • relations.sourceKey: qual a coluna de recionamento no resource MASTER
    • relations.targetKey: qual a coluna de relacionamento no resource DETAIL
    • relations.join: utilizado para JOINs mais complexos ignorando “sourceKey” e “targetKey”

Listagem completa do metadata de exemplo

[code lang=”javascript”]
{
"@odata.context": "http://localhost:8080/OData/OData.svc",
"__comment": "Services list all resource available to OData.Service",
"OData.Services": [
{
"resource": "produtos",
"collection": "produtos",
"keyID": "codigo",
"maxpagesize": 100,
"fields": "*",
"method": "GET,PATCH,POST,PUT,DELETE",
"relations": [
{
"resource": "grupos",
"sourceKey": "grupo",
"targetKey": "codigo",
"join": "left join grupos on (produtos.grupo=grupos.grupo)"
}
]
},
{
"resource": "grupos",
"collection": "grupos",
"keyID": "codigo",
"fields": "*",
"method": "GET,PATCH,DELETE,PUT,POST",
"maxpagesize": 100,
"relations": [
{
"resource": "produtos",
"sourceKey": "codigo",
"targetKey": "grupo",
"join": "join produtos on (grupos.codigo=produtos.grupo)"
}
]
},
{
"resource": "fornecedores",
"collection": "fornecedores",
"maxpagesize": 100,
"fields": "*",
"keyID": "codigo"
},
{
"resource": "clientes",
"collection": "clientes",
"keyID": "codigo",
"method": "GET,POST,PATCH,UT,DELETE",
"searchFields": "nome",
"maxpagesize": 100,
"fields": "*"
"relations": [
{
"resource": "vendas",
"join": "join vendas on (vendas.cliente=clientes.codigo)"
},
{
"resource": "vendas_item",
"join": "join vendas a on (clientes.codigo=a.cliente) join vendas_item b on (b.documento=a.documento)"
}
]
},
{
"resource": "vendas",
"collection": "vendas",
"maxpagesize": 100,
"keyID": "documento",
"fields": "*",
"method": "GET,POST,PATCH,PUT,DELETE"
},
{
"resource": "vendas_item",
"collection": "vendas_item",
"maxpagesize": 100,
"keyID": "documento"
"method": "GET,POST,PATCH,PUT,DELETE"
}

]

}
[/code]

 

por ·0 comentários

 

Chegar a um CRUD é um grande desafio. Associar um MVC no desenvolvimento e a utilização de RESTful para persistir os dados (com OData) só faz crescer o desafio.

O desafio vem do fato de tudo ser novidade e forçar a quebrar paradigmas antes impensáveis utilizando a ferramenta do dia-a-dia, o Delphi.

Vamos ligar os componentes:

TIdHTTPRestClientTIdHTTPRestClient é responsável em fazer a
comunicação entre o cliente e o servidor RESTful.

É o canal para buscar dados no servidor, bem como enviar dados para o servidor (é um componente de transporte).

ver mais…

 

 

Os preenchimento das propriedades do RestClient pode ser feito manualmente, ou ainda, de forma automática se for utilizado em conjunto com um TODataBuilder.

 

ODataCom o TODataBuilder permite construir a soliciatação GET a ser enviada ao servidor OData.

Ligar ao TODataBuilder a propriedade RestClient com o TIdHTTPRestClient. Com isto o comando construído no Builder será repassado (preenchido automático) no RestClient.  ver mais….

 

 

 

O passo seguinte é ligar o TODataDatasetAdpater.

TODataDatasetAdapterO Adapter recebe os dados do RestClient e liga com o Dataset.

Ligar o Builder, Dataset e o ResponseJSON( RestClient).

Para obter os dados com os servidor, chamar o método execute. ver mais…

Feito estas ligações nos componentes, já é possível chamar o EXECUTE do Adapter que irá preencher o Dataset com a resposta do servidor.

Para enviar um INSERT, DELETE ou UPDATE para o servidor ( ver exemplo).

O código a seguir mostra como montar os dados a serem enviado para o servidor persistir as alterações.

Os seguintes métodos do Adapter são importantes, como no exemplo:

ODataDatasetAdapter1.AddRowSet(rctInserted, DataSet); /// põe na pilha um INSERT;
ODataDatasetAdapter1.AddRowSet(rctModified, DataSet);  /// põe na pilha um UPDATE
ODataDatasetAdapter1.AddRowSet(rctDeleted, DataSet);  /// põe na pilha um DELETE;
ODataDatasetAdapter1.ApplyUpdates(nil, rmPATCH);  /// atualiza o servidor com os dados da pilha;
ODataDatasetAdapter1.Execute;   /// faz um SELECT no banco de dados
ODataDatasetAdapter1.ClearChanges;  /// limpa a pilha

 

Código de exemplo que esta no projeto MVCBr.  no git

[code lang=”pascal”]
{ //************************************************************// }
{ // // }
{ // Código gerado pelo assistente // }
{ // // }
{ // Projeto MVCBr // }
{ // tireideletra.com.br / amarildo lacerda // }
{ //************************************************************// }
{ // Data: 10/03/2017 21:21:54 // }
{ //************************************************************// }
///
/// Uma View representa a camada de apresentação ao usuário
/// deve esta associado a um controller onde ocorrerá
/// a troca de informações e comunicação com os Models

….
DBGrid1: TDBGrid;

DataSource1: TDataSource;
/// Componente de Envio de mensagem HTTP para o servidor OData RESTful
IdHTTPRestClient1: TIdHTTPRestClient;
/// Construção de URL a ser enviado ao servidor
ODataBuilder1: TODataBuilder;
/// Desempacota a resposta do servidor e preenche o Dataset
ODataDatasetAdapter1: TODataDatasetAdapter;

/// Dataset que recebe a resposta do servidor – preenchida com o Adpater
FDMemTable1: TFDMemTable; /// FireDAC
Button1: TButton; /// botão GET
Button2: TButton; /// botão ApplayUpdates
….
private
FLoading: boolean; /// Flag para marcar se esta fazendo carga inicial da tabela.
FState: TDataSetState; /// Guarda o STATE do Dataset a ser usando no AfterPost
protected
public
{ Public declarations }
…
end;

Implementation

{$R *.DFM}

…..
/// No evento AfterPost do Dataset, armazena na lista de
/// alterações a serem enviadas para o servidor OData RESTful
procedure TRestODataAppView.FDMemTable1AfterPost(DataSet: TDataSet);
begin
if not FLoading then /// trata somente os registros alterados pelo usuário… (para não pegar os dados iniciais na carga da resposta do servidor)
case FState of
dsInsert: /// empilha os dados de INSERT – inserted
ODataDatasetAdapter1.AddRowSet(rctInserted, DataSet);
dsEdit: /// empilha os dados do POST – modified
ODataDatasetAdapter1.AddRowSet(rctModified, DataSet);
end;

end;

/// No ApplyUpdates do Dataset despachar para o servidor
/// as alterações armazenadas para serem notificadas
/// ao servidor
procedure TRestODataAppView.FDMemTable1BeforeApplyUpdates(DataSet: TFDDataSet);
begin
// envia os dados alterados para o servidor OData RESTful
ODataDatasetAdapter1.ApplyUpdates(nil, rmPATCH);
end;

procedure TRestODataAppView.FDMemTable1BeforeDelete(DataSet: TDataSet);
begin
/// empilha os dados a serem de DELETE – deleted a ser enviado ao servidor
ODataDatasetAdapter1.AddRowSet(rctDeleted, DataSet);
end;

procedure TRestODataAppView.FDMemTable1BeforePost(DataSet: TDataSet);
begin
/// guarda o estado da linha (dsEdit, dsInsert) para uso no AfterPost
FState := DataSet.State;
end;

procedure TRestODataAppView.FormCreate(Sender: TObject);
begin
/// um exemplo de como adicionar CustomHeaders a mensagem que será enviada ao servidor
IdHTTPRestClient1.IdHTTP.Request.CustomHeaders.AddValue(‘token’, ‘abcdexz’);
end;

procedure TRestODataAppView.Button1Click(Sender: TObject);
begin
FLoading := true; /// controle para não gerar linhas de alterações na pilhas
try
/// executa um GET no servidor RESTful
/// o servidor fazer um SELECT e devolve o conteúdo as linhas do SELECT
ODataDatasetAdapter1.Execute;
/// limpa alterações que estejam armazenadas
ODataDatasetAdapter1.ClearChanges;
finally
FLoading := false;
end;
end;

procedure TRestODataAppView.Button2Click(Sender: TObject);
begin
FDMemTable1.ApplyUpdates(); /// processa a alteração do Dataset
end;

[/code]

 

por ·0 comentários

O componente TODataDatasetAdapter é um construtor associado ao Dataset convertendo o JSON enviado pelo servidor em um DATASET navegável no formulário. Vejamos suas propriedades.

TODataDatasetAdapter Onde:
Builder: ligação para o TODataBuilder;
Datasert: ligação para um TFDMemTable (aka. TClientDataset !!!);
ResponseJSON: ligação com o TIdHTTPRestClient;
ResponseType: no momento só aceita texto plano sem compactação – pureJSON;
RootElement:  caminho onde se encontra o ARRAY de valores no JSON enviado pelo servidor (no OData o padrão é “value”);
Introdução ao OData | TODataBuilder | TIdHTTPRestClient

 

por ·0 comentários

TODataBuilder é um construtor de URI para chamada ao OData Server.

OData

O construtor  é uma facilidade para criar a URI de chamada ao OData através da interface gráfica do Delphi onde:

  • BaseURL – Servidor e porta do OData;
  • Count – indica se é para retornar o número total de linhas do select – usado para paginação;
  • Expand – lista de Resource DETAIL   (não implementado no MVCBrServer neste momento);
  • Filter – filtro de contrução auxiliar para o cláusula WHERE de busca no banco de dados (aceita os operadores do OData);
  • Resource – lista de Collections/Tabelas e respectivos parâmetros aninhadas ( max 3 );
  • Select – lista de colunas a retornar pelo consulta no servidor;
  • Service – nome do serviço no servidor;
  • ServicePreffix – prefixo de composição da URI associado ao Serviço;
  • SkipRows – indica quantas linhas saltar antes de retornar o conjunto de linhas (default=0);
  • TopRows – indica a quantidade de linhas a serem retornadas (default=0  todas);

O componente expõe o metódo “execute” que tem por atribuição preencher os parâmetros do TIdHTTPRestClient e chamar o seu “execute”;

RestClient | Introdução ao OData

 

por ·1 Comentário

TIdHTTPRestClient é um cliente RESTful implementado sobre o componente INDY  TIdHTTP de uso geral.

TIdHTTPRestClient

 

O procedimento “execute” do componente envia uma solicitação ao servidor HTTP e aguarda resposta pela propriedade “content”.

Propriedades

  • BaseURL – servidor e porta de acesso;
  • Method – identifica o método a ser executa no servidor;
  • Resource – URL de acesso;
  • ResourcePreffix – Serviço de acesso no servidor;

 

Informações adicionais de HEADER deve ser enviado através da propriedade do componente “IdHTTP” que expõe o componente TIdHTTP instanciado internamente.

Exemplo de envio de “token” no HEADER:

   IdHTTPRestClient1.IdHTTP.Request.CustomHeaders.AddValue('token','abcdexz');

Se necessário obter informações adicionais é possível obter a partir de documentação do TIdHTTP e pode ser aplicado a propriedade IdHTTPRestClient1.IdHTTP…

Introdução ao OData

por ·0 comentários

Nos textos anteriores foi possível destacar como fazer INSERT, DELETE e UPDATE – cada um individualmente em comandos separados.

Aqui vamos mostrar o METHOD   PATCH. Na especificação padrão do RESTful o PATCH efetua um UPDATE no banco de dados. Qual então a diferença entre PUT e PATCH ? Regra geral no OData, o comando PUT faz update de todas as colunas da tabela, enquanto o PATCH faz igualmente um update, no entanto realiza atualização somente nas colunas indicadas no BODY.method-patch

No MVCBrServer, o PUT e o PATCH possuem as mesmas funcionalidades, ou seja, atualizam somente as colunas indicadas no BODY como já visto no texto que discorremos sobre o METHOD PUT.

Uma variação implementada no MVCBrServer é a possibilidade do comando PATCH executar múltiplas funções e aceitar enviar INSERT, DELETE e UPDATE dentro de um mesmo ARRAY com as linhas de comando.

Para executar múltiplas funcionalidade, cada linha deve ser indicada com uma propriedade “rowstate” com um dos valores: “modified”, “inserted”, “deleted”.

Exemplo:

url: http://localhost:8080/OData/OData.svc/vendas()
body:
[
   { "rowstate":"deleted","data":"2017-03-17","documento":3},
   { "rowstate":"inserted","data":"2017-03-17","documento":3,"cliente":1,"total":10},
   { "rowstate":"modified","data":"2017-03-17","documento":3,"cliente":2,"total":10}
]

 

Este BODY envia 3 comandos no mesmo ARRAY que serão executados na seguinte ordem:

  1. na linha 1 o “rowstate”:”deleted” indica que a linha deve ser processada como um comando DELETE;
  2. na linha 2 o “rowstate”:”inserted” indica que a linha é um INSERT;
  3. na linha 3 o “rowstate”:”modified” deve processar um UPDATE para a linha;

Resposta:
{"@odata.context":"\/OData\/OData.svc\/vendas()","StartsAt":"2017-03-17T20:45:46.541Z",
 "@odata.count":"3","EndsAt":"2017-03-17T20:45:46.559Z"}

Em relação ao controle de transação da operação o controle ocorre no mesmo formato que já tratamos aqui ACID , ou seja – tudo ou nada.

 

Introdução ao OData

por ·0 comentários

O protocolo OData não trata sobre o controle de transação do banco de dados. Esta é na verdade um decisão do server que implementação será feita. Como o OData nasce em um ambiente noSQL com forte presença é fácil imaginar que o controle de transação é uma preocupação mais presente no legado e menos presente nas novas tecnologia.
Aqui um paradigma bom a ser vencido ao longo dos anos – como sair de um ambiente transacional e abandonar o ACID no noSQL…

Aqui no MVCBrServer o banco de transação é o Firebird e a transação faz parte da estrutura de controle. Pensando nisto, quando o cliente solicita um conjunto de linhas em um ARRAY o server faz um STARTTRANSACTION e somente após a conclusão de todas as linhas irá enviar um COMMIT para o servidor.
Caso ocorra algum erro durante o processo um ROLLBACK é enviado para o servidor cancelando todo o lote da transação.

introdução a OData | INSERT | UPDATE