Voir la source de Service Proxy de base de données (server)

{{latest}}
__TOC__

Le service proxy de base de données permet d'accéder aux bases de données à travers le service Sage FRP 1000. 

Ce est utile lorsque les bases de données ne peuvent pas être exposées, par exemple dans un environnement hébergé Web.

L'interface duservice proxy est basée sur une interface REST

===Service URL.===
Le service proxy est accessible à travers l'url de base du service :

<pre>
 https://domain/service/sql
</pre>

*domaine
:Domaine du service

*service
:Service Sage 1000 du service.

===Ressources URI.===
Une ressource à un type et un identifiant, le type est utilisé dans la signature, l'identifiant dans l'URI.

Les identifiants de ressources :

<pre>
 /databaseType/uriID
</pre>

===Entête de requête.===
Les requêtes HTTP doivent contenir les entêtes suivantes :

{|class="wikitable"
|-
!Entête
!Usage
!Valeur
|-
|x-ms-version
|Version de service proxy
|2017-01-01
|-
|x-ms-date
|Heurodatage de la requête
|Example, Tue, 13 Dec 2016 08:35:12 GMT
|-
|Authorization
|Doit contenir un token de signature de la requête.
|Example, type%3DInfineo%26ver%3D1.0%26sig%3DUoJIc0H4RlcUn3Jme53QUNR2cVAnlawVX52pEDD%2BBaI%3D 
|-
|ContentType
|Définit le type de contenu de la requête
|application/sql
|-
|Accept
|Définit le type de contenu de la réponse
|application/xml
|-
|Accept-Encoding
|Définit le type d'encoding de la réponse
|gzip
|-
|Cookie
|Doit contenir le cookie de session de l'utilisateur
|Example, SID=208393202-5A950A00000003........
|}

===Authentification de l'utilisateur.===
Il existe deux méthodes pour authentifier l'utilisateur :
* Utiliser une connexion de service a travers [[Connect_(sdata)|l'api sdata $connect]]
* Utiliser le dialogue standard de connexion de l'utilisateur

La méthode utilisant le dialogue standard est préférable parce qu'elle gère l'ensemble des paramètres d'authentification.

Dans les deux cas vous devez obtenir en fin d'authentification le SID de session de l'utilisateur et passé ce SID dans un cookie de session de nom "SID" et posé sur l'url du service ( https://domaine/service )

====Authentification en utilisant $connect====
L'authentification par la méthode [[Connect_(sdata)|$connect]] permet de retrouver directement le SID de la session.

====Authentification en utilisant le dialogue Web d'authentification====
Le dialogue standard d'authentification de l'utilisateur peut être appelé à l'url suivante :

<pre>
 https://domaine/service/server/connect.l1000?cburl=url_redirect_success
</pre>

Par défaut le dialogue standard retourne le SID de la session dans un cookie ayant l'attribut "httponly", de ce fait il n'est pas possible de récupérer en dehors du contexte html. 

Pour obtenir le cookie de session, il faut exécuter l'url de service retournant les informations de session en passant un paramètre "returnSID=1" 

Pour ce faire :

A la fin de la procédure d'authentification le dialogue navigue sur l'url passée en paramètre (url_redirect_url).

Cette url doit être interceptée et redirigée sur url suivante :

<pre>
 https://domaine/service/server/rpc.l1000/info.context?returnSID=1
</pre>

Dans la réponse du serveur, le SID est présent dans l'élement <SIDC>.

Ce SID est crypté 3des par la clé de chiffrement de l'application et encodé en base 64.

===Authentification de l'application.===
L'application appelante doit être authentifiée et autorisée, elle doit être enregistrée en tant d'application de service.

L'enregistrement d'une application fournit deux valeurs :
* Un identifiant d'application. (Exemple, Infineo)
* Une clé de chiffrement symétrique encodée en base 64 (Exemple, 0vGbKhRbJHDKdG8j755r75N1hozxAQGbo2fxzWNMcBc=)

Ces identifiants doivent être utilisés dans la signature des requêtes.

[[image:application-de-service-1.png]]

===Signature des requêtes.===
Les requêtes HTTP émises sur le service proxy doivent être signées, le résultat de la signature est formaté dans un jeton qui doit être passé dans l'entête Authorization de la requête.

La méthode de signature des requêtes est basée sur [https://docs.microsoft.com/en-us/rest/api/documentdb/access-control-on-documentdb-resources Access control on DocumentDB resources]

Cette méthode est décrite ainsi :
* Un payload est construit à partir des informations de la requête.
* Ce payload est signé avec la clé de chiffrement de l'application.
* Un jeton encapsule la signature.
* Ce jeton est passé dans l'entête Authorization de la requête.

Le code de signature et de construction du jeton est le suivant :

<pre>
function TSage1000ApplicationKey.Sign(const iVerb,iResourceType,iResourceID:string; iHeaderDate:TDatetime):string;
begin
  (*
  payLoad to sign
  1. VERB.toLowerCase() + "\n" +
  2. ResourceType.toLowerCase() + "\n" +
  3. ResourceId + "\n" +
  4. (headers["x-ms-date"] || "").toLowerCase() + "\n" +
  5. (headers["date"] || "").toLowerCase() + "\n";
  resourceType ==  "dbs", "colls", "docs"
  x-ms-date is the UTC date and time the message was sent (in "HTTP-date" format as defined by RFC 7231 Date/Time Formats) e.g. Tue, 15 Nov 1994 08:12:31 GMT.
  *)

  lastPayLoad := lowerCase(iVerb)+#10+lowerCase(iResourceType)+#10+iResourceID+#10+lowerCase(LocalDateTimeToGMT(iHeaderDate))+#10#10;
  lastSign := THMACUtils<TIdHMACSHA256>.HMAC_KeyBase64_Base64(KeyValue, lastPayLoad);

  lastToken := Format('type=%s&ver=1.0&sig=%s',[KeyName,lastSign]);
  Result := HTTPEncode(lastToken);
end;
</pre>

où

*KeyName
:L'identifiant de l'application

*KeyValue
:la clé de chiffrement de l'application

*iVerb
:Le verbe http utilisé (ex: POST)

*iResourceType
:Le type de la ressource. (ex: cursor)

*iResourceID
:L'identifiant de la ressource. (ex: open)

*iHeaderDate
: L'horodatage utilisé dans l'entête ms-x-date

===Code de retour===
{|class="wikitable"
|-
!Code
!Usage
|-
|500
|Bad request
|-
|501
|Not implemented
|-
|401
|Unautorized
|-
|403
|Forbidden
|-
|200
|OK
|}

===Type de contenu de la réponse (XML)===
Les réponses au format XML respectent le schéma suivant :

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<result eof="1">

<columns>
  <c id="0" type="column_type" len="column_length">column_name</c>
  ...
</columns>

<rows>
<r>
 <v id="0" null="1" blob="1">value</v>
 ...
</r>
....
</rows>

</result>
</pre>

Si les attributs de type boolean sont présent (Ex: eof,null,blob...) leur valeur est 1, ils sont absent si leur valeur est False.

Column_type est le type de l'attribut Sage 1000

{|class="wikitable"
|-
!Type Sage 1000
|Type SQL Server
|-
|absftUnknown
|
|-
|absftOID
|
|-
|absftOIDChar
|
|-
|absftVarchar
|
|-
|absftInteger
|
|-
|absftFloat
|
|-
|absftCurrency
|
|-
|absftDateTime
|
|-
|absftMemo
|
|-
|absftBinary
|
|-
|absftLongInt
|
|-
|absftNVarchar
|
|-
|absftNMemo
|
|-
|absftBool
|
|-
|absftSmallInt
|
|-
|absftStamp
|
|}

===Curseurs===
Les ressources de type curseur exécute un select sur une base de données et retourne les données en résultat.

Les identifiant de ressource URI utilisés par un curseur :

{|class="wikitable"
|-
!Type 
!Identifiant 
!Usage
|-
|cursor
|open
|Ouverture du curseur 
|-
|cursor
|next
|Valeurs suivantes
|-
|cursor
|close
|Fermeture du curseur
|}


[[Category:Latest]]
[[Category:Serveur]]