Makes it easy to connect OpenERP to other systems that could introspect the services offered by the server instead of requiring prior knowledge of it

Registered by Raphaël Valyi - http://www.akretion.com on 2008-11-29

Notice this has been discussed previously on the forum here: http://openerp.com/forum/topic6125.html?highlight=introspection

Actually, what is need is the standard described here for instance:
http://xmlrpc-c.sourceforge.net/introspection.html

So if asked to list his methods, the server must answer the list of all available methods. If there are too much, possibly split those my module, providing an other introspection method that would list the installed modules. The server should also list the exposed methods no matter which roles/users might use them or not.

It's not that much about perfectly adhering to the standard than being able to introspect the server.

Why? By doing this, we would make it easier for third party to offer GUI interfaces to interact with OpenERP. By offering introspection features, we make this far easier because the third party interface could just ask to user to navigate to the appropriate service instead of hardcoding very possible call, method by method, not speaking about following API evolutions closely.

This would make it pretty much like when you use some ETL like Kettle or Talend to connect to a database, the JDBC driver usually offer some database introspection capabilities so you can list the available tables and columns the user can select for its transformation.

Targeted third party softwares are ETL indeed, but also ESB like ServiceMix or externalized BPM engines like Intalio BPM (I know that the built'in OpenERP BPM engine is very good already and very intgrated, but large companies might also need some external SOAP enabled and user friendly BPM engine).

I discussed this with Stephane Wirtel from Tiny.be and he told me that listing methods implemented in the addons modules would be easy using Python introspection for instance, while osv and orm layer methods like the CRUD (create read update or unlink) methods would probably have to be listed from some hardcoded list. No problem with that. osv/orm methods are stable indeed and could probably hardcoded while what really matter are functionnal methods implemented in the functionnal modules.

Also, webservice intropsection only matter for XML/RPC (or SOAP eventually or better REST, the Rails way), not for Net/RPC. Indeed, what is need is a cross language introspection capabililty. Also performance doesn't matter much here.

Raphaël Valyi.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
Stephane Wirtel (OpenERP)
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Update: I see that actually only the "execute" method is used. This isn't really introspectable in the standard way. Still I think you should provide some introspection abilities, be it using an other communication layer such as REST on HTTP.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.