Przepływ danych i sterowania

W programach webowych przepływ danych przebiega nieco inaczej niż w aplikacjach client-server (opartych na bazach danych programach w lokalnej sieci lub na pojedynczym komputerze). Program może odbierać wiele zapytań równocześnie od różnych użytkowników. Ustalenie tego od kogo przychodzi zapytanie i w jakim kontekście je zadano jest problemem.

Problem ten rozwiązuje się przy pomocy sesji i ciasteczek (cookies).

Ciasteczko session_id

Po uruchomieniu strony aplikacji Odoo w przeglądarce, możemy znaleźć informację o zostawionych na naszym komputerze ciasteczkach (w Google Chrome: narzędzia programisty - application - storage). Kluczowe dla przepływu znaczenie ma w ciasteczku Odoo pole o nazwie session_id. (Prócz tego można znaleźć np. pole website_lang zawierające informacje o wybranym języku).

Jaśli na przykład session_id=4a44ecc02dcbad2abf659099d9853d43e70e1d2c to możemy odszukać plik sesji na serwerze:
~/.local/share/Odoo/sessions/werkzeug_4a44ecc02dcbad2abf659099d9853d43e70e1d2c.sess

Są tam przechowywane dane związan z sesją. Między innymi:

  • login - login użytkownika
  • password - hasło
  • db - nazwa przyłączonej bazy danych
  • lang - język
  • tz - strefa czasowa
  • context - kontekst

Implementację związku sesji z ciasteczkami wyjaśniono w dokumentacji biblioteki werkzeug: http://werkzeug.pocoo.org/docs/0.14/contrib/sessions/

Z kolei http://werkzeug.pocoo.org/docs/0.14/wrappers/ wyjaśnia używanie obiektów Request i Response. Szczegóły Request: https://www.odoo.com/documentation/9.0/reference/http.html#request.

Po otwarciu strony następuje routing (http://werkzeug.pocoo.org/docs/0.14/routing/) - czyli wybór odpowiedniej dla danego adresu funkcji kontrolera. Ustalany jest kontekst, użytkownik, język i baza danych. Jeśli używamy dekoratorów - to wszystko dzieje się automatycznie i bez naszego udziału (w tle).

Zobacz też: http://www.mindissoftware.com/Odoo-Load-Addons-And-Modules/

XML-RPC

Nieco inny przebieg ma sterowanie, gdy chcemy sięgać po dane z Odoo z innej aplikacji (Odoo jako web services: http://www.surekhatech.com/blog/working-with-odoo-web-services). W takich przypadkach mamy prosty mechanizm pytanie-odpowiedź z wykorzystaniem protokołu XML-RPC. Udostępnia też bogate API dostępne przez XML-RPC (zob.: https://www.odoo.com/documentation/8.0/api_integration.html).

Przykład zdalnego wywołania:

import xmlrpclib
server_url = 'http://127.0.0.1:8069'

common = xmlrpclib.ServerProxy('{}/xmlrpc/2/common'.format(server_url))
print common.version()

A oto ten sam przykład w języku Java:

package odoo.Test1;


import java.net.URL;
import java.util.Map;
import java.util.Vector;

import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.client.XmlRpcClient;
import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;

import java.net.MalformedURLException;

public class App {
  public static void main( String[] args )  {
    String common_url = "http://127.0.0.1:8067/xmlrpc/2/common";
    String methodName = "version";
    XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl();
    try {
     config.setServerURL(new URL( common_url ));
     XmlRpcClient client = new XmlRpcClient();
     client.setConfig(config);
     Vector params = new Vector();
     try {
       @SuppressWarnings("unchecked")
       final Map<String, String> info = 
          (Map<String, String>) client.execute(config, methodName, params);
       final String server_version = info.get("server_version");
       System.out.println(server_version);
     } catch (XmlRpcException e) {
    e.printStackTrace();
     }
   } catch (MalformedURLException e) {
      System.out.println("MalformedURLException");
   } finally {
      System.out.println( "Koniec!" );
   }         
  }
}

Więcej informacji:

Stosując powyższe API można zbudować aplikację całkowicie niezależną - w dowolnym języku i na dowolną platformę. Tu przykładowa aplikacja na Androida: https://github.com/odoo-mobile-intern/odoo-work