(Migrated) OpenERP support in Zato

(This message has been automatically imported from the retired mailing list)

Hello,

I’ve noticed interest in Zato among OpenERP users - some of you are
already subscribed to this list - and I’d like to strike up conversation
on how best to foster the interest and improve OpenERP support in Zato.

For those hearing of Zato the first time - it’s a Python-based
open-source Enterprise Service Bus (ESB) in Python designed for
integrations and building application in Service-Oriented Architecture
(SOA).


https://zato.io/docs/intro/esb-soa.html

Both projects will be used in similar settings though naturally OE is a
well established one and Zato is just starting out (the first release
was 2 months ago).

Right now Zato has generic support for a lot of technologies (AMQP,
HTTP, JSON, SOAP, JMS WebSphereMQ, ZeroMQ, FTP) but I’d like to talk
with you about treating OE as a first-class citizen.

Next few Zato versions will start adding clients to particular business
applications and it would be great if OE was one of them.

I’m thinking of creating an XML-RPC client that will make it possible to
expose OE’s API through any Zato-supported access methods, so for
instance, the same OE API will be accessible through JSON/SOAP for
synchronous invocations by client applications and through MQ for batch
upload of data.

I’ve spoken about it off-list a bit with Guewen Baconnier who helped me
find my way around OE’s runbots/services/docs and I think this should be
doable. I’ve seen latest OE versions added JSON-RPC but I guess it will
be best to use XML-RPC in order to be able to target previous OE
versions too?

It would be great if you could help me by telling me more what sort of
integration scenarios or issues you’re facing and would need help in
tackling or what sort of integration patterns you deal with that need
implementing all the time in various modules - such things should
preferably be taken out and codified in an integration platform (Zato)
and I’d be happy to do it. What sort of things your customers ask for?
How would you like to integrate with external apps? Basically, how Zato
can help you in your job? How can I assist you in getting started quickly?

Also, given that OE companies already use Python and are looking for
Python-based solutions primarily, Zato can be the next step in your
portfolio towards a complete offer of enterprise solutions and can be
seen as an OE’s logical continuation and supplement - Zato’s focus will
be always on data acquisition, exchange, business integrations and
process automation across multiple applications. This is another topic
that would be very interesting to talk about.

many thanks for your input,

Hi Dariusz,

On Sun, Jul 14, 2013 at 1:07 PM, Dariusz Suchojad dsuch@zato.io wrote:

Hello,

I’ve noticed interest in Zato among OpenERP users - some of you are
already subscribed to this list - and I’d like to strike up conversation on
how best to foster the interest and improve OpenERP support in Zato.

I like your interest in get works OpenERP and Zato.

For those hearing of Zato the first time - it’s a Python-based open-source
Enterprise Service Bus (ESB) in Python designed for integrations and
building application in Service-Oriented Architecture (SOA).

http://www.infoq.com/articles/**zato http://www.infoq.com/articles/zato
https://zato.io/docs/intro/**esb-soa.htmlhttps://zato.io/docs/intro/esb-soa.html

Both projects will be used in similar settings though naturally OE is a
well established one and Zato is just starting out (the first release was 2
months ago).

Right now Zato has generic support for a lot of technologies (AMQP, HTTP,
JSON, SOAP, JMS WebSphereMQ, ZeroMQ, FTP) but I’d like to talk with you
about treating OE as a first-class citizen.

Next few Zato versions will start adding clients to particular business
applications and it would be great if OE was one of them.

I’d love be part of that, i want to learn about Zato, my company works with
OpenERP at full time.

I’m thinking of creating an XML-RPC client that will make it possible to
expose OE’s API through any Zato-supported access methods, so for instance,
the same OE API will be accessible through JSON/SOAP for synchronous
invocations by client applications and through MQ for batch upload of data.

Here there is some works around like openerplib (inside openerp).

I’ve spoken about it off-list a bit with Guewen Baconnier who helped me
find my way around OE’s runbots/services/docs and I think this should be
doable. I’ve seen latest OE versions added JSON-RPC but I guess it will be
best to use XML-RPC in order to be able to target previous OE versions too?

I am agree with you support XML-RPC is a good option, there is many clients
using v6.0 and v6.1, this versions dont support JSON.

It would be great if you could help me by telling me more what sort of
integration scenarios or issues you’re facing and would need help in
tackling or what sort of integration patterns you deal with that need
implementing all the time in various modules - such things should
preferably be taken out and codified in an integration platform (Zato) and
I’d be happy to do it. What sort of things your customers ask for? How
would you like to integrate with external apps? Basically, how Zato can
help you in your job? How can I assist you in getting started quickly?

Also, given that OE companies already use Python and are looking for

Python-based solutions primarily, Zato can be the next step in your
portfolio towards a complete offer of enterprise solutions and can be seen
as an OE’s logical continuation and supplement - Zato’s focus will be
always on data acquisition, exchange, business integrations and process
automation across multiple applications. This is another topic that would
be very interesting to talk about.

In fact i want to learn to do exactly what you say :).

I think we can start to work in integration, while i am learn Zato.

Regards,

many thanks for your input,


Dariusz Suchojad

https://zato.io
ESB, SOA and cloud integrations in Python
_____________**
Zato-discuss mailing list
Zato-discuss@lists.zato.io
https://mailman-mail5.**webfaction.com/listinfo/zato-**discusshttps://mailman-mail5.webfaction.com/listinfo/zato-discuss

On 07/15/2013 03:56 AM, Ovnicraft wrote:

Hi Ovnicraft:-)

Right now Zato has generic support for a lot of technologies (AMQP,
HTTP, JSON, SOAP, JMS WebSphereMQ, ZeroMQ, FTP) but I'd like to talk
with you about treating OE as a first-class citizen.

Next few Zato versions will start adding clients to particular
business applications and it would be great if OE was one of them.

I’d love be part of that, i want to learn about Zato, my company works
with OpenERP at full time.

OK, this is great to hear!

I’ve started a zato-labs project to implement the client here

https://github.com/zatosource/zato-labs/tree/master/openerp-client

The concept with zato-labs is that the core platform is extensible and
new ideas can be implemented in labs without releasing a full Zato version.

Stuff added to labs is also much lighter, there’s no GUI nor API - and
before turning these zato-labs ideas into Zato’s built in features
GUI/CLI/API must be added along with a lot of docs and usage examples
(I’d like Zato to be known around for its special attention paid to docs).

I’m looking at the openerp-client-lib package

and I’d like to make it possible to express OpenERP calls from within
services in a way similar to below

oe = self.openerp.get(‘my-instance’).conn
ids = conn.search({‘login’:‘admin’})

That would be the whole code needed to invoke OE’s API from a service
and all the connection details/session management would be dealt with by
Zato - conn details would be provided through GUI/CLI/API by admins,
like it’s done with AMQP/HTTP/ZeroMQ/etc. in Zato now - this way you
could switch between OE instances or reconfigure everything without any
restarts

https://zato.io/docs/web-admin/channels/amqp.html
https://zato.io/docs/web-admin/outgoing/plain-http.html
https://zato.io/docs/web-admin/outgoing/zmq.html

Making such a convenience client would be a start and on top of that we
can next think of making the client itself be easily available through
all the protocols Zato supports.

Though remember that being in zato-labs means there will be no GUI
support for it, this will have to wait for a proper release. (Actually,
the platform is /almost/ at the point where new GUI/CLI/API parts can be
added by external add-ons but it’s not there yet)

I’d like to provide the core of OE client and it would be great to
collaborate on it together!

Also, given that OE companies already use Python and are looking for
Python-based solutions primarily, Zato can be the next step in your
portfolio towards a complete offer of enterprise solutions and can
be seen as an OE's logical continuation and supplement - Zato's
focus will be always on data acquisition, exchange, business
integrations and process automation across multiple applications.
This is another topic that would be very interesting to talk about.

In fact i want to learn to do exactly what you say :).

I think we can start to work in integration, while i am learn Zato.

Sure thing, if you could tell me a bit more about environments you
potentially think of using an integration platform in, I’m sure I’ll be
able to help you with designing things, picking these parts of Zato that
will work best for you or just understand that such and such thing needs
to be added to the platform because you (=others certainly too) need it.

It’s really best to approach everything in a top-down manner. By
thinking in terms of business processes happening around and decomposing
them into smaller pieces (use-cases) that are interesting, reusable,
atomic and can be implemented as services in Zato. This is the same
thing as described here https://zato.io/docs/intro/esb-soa.html

It’s OK to initially think of everything in terms of interfaces, data
exchange or data sources and targets but the real power of an ESB is
when you actually put services in the center of everything - without
approaching everything in such a way an ESB will be only a convenient
layer to integrate applications. This is useful too and will save you
work but there can be more value added if you think of it as a container
for useful services that co-operate to achieve interesting results.

Designing ESB/SOA services is quite akin to designing an API - with an
API some methods will be public, some will stay private (they’re not
reusable in a wider context), they all are used to achieve something
useful that can be reused over and over in other contexts. In API
certain parts should never be visible to users and same will go with
services.

The state to attain is that when you finish a SOA project and there’s
another one coming up and someone asks you what you can deliver you
should be able to state that you can quickly offer the same
functionality as the previous project without any programming needed -
everything should only be a matter of parametrization. This naturally
takes practice, experience and good judgement but it’s doable. You just
need to put re-usability, atomicity and how much services can be
interesting to their users in the centre of everything.

Why do I emphasize the part of being interesting? Because it’s easy to
treat SOA as a buzzword and turn /everything/ into a service. Format
lost focus and zip code needs validation? Invoke a service. Leaving
screen for another - invoke a service to save state. Etc. etc. Thinking
in that terms leads to disasters, abysmal performance and to quick
system rewrites (if such projects are allowed to complete at all). Such
functionalities are not interesting - where is business value and
reusability in it? There is none of course and you must sure you don’t
go that way.

Given that we’re all Python programmers here I can also say that the
goal is to make services Pythonic. Clean, nice, interesting from the
business perspective, adorable and easy to use in multiple places.

ESB will help you by giving you trivial access to multiple
protocols/data formats and integration patterns, such as various
invocation types (sync/async/with callbacks or not), the ability to ask
several systems for data, serially or in parallel, distributed
transactions, security, guaranteed delivery, caching and some more. Not
every part of it is already done in Zato but it will be added with each
new release. On top of that Zato has clusters, hot-deployment, GUI, CLI,
API and other tooling featurs that any server should have anyway.

Zato will also with time have graphical means to orchestrate and
coordinate services but I have no plans to turn it into a full Business
Process Management suite (BPM) with document flow, human tasks etc. This
is another breed of software that Zato is not.

On 07/15/2013 10:45 AM, Dariusz Suchojad wrote:

I’ve started a zato-labs project to implement the client here

https://github.com/zatosource/zato-labs/tree/master/openerp-client

OK, the client turned out to be a thin one as pretty much everything is
done by openerplib

Here’s a sample service that connects to an OE instance and grabs some
data. Such a service can accept or produce data from/to XML, JSON, AMQP,
HTTP, ZeroMQ and any other supported by Zato.

About the only caveat is that the connection is established each time
the self.openerp.get method is invoked - it’s not stored anywhere in
between the calls. This will be lifted before the client is added to the
core.

I didn’t change the syntax used to invoke OE API in the end - gave it
some more thought and leaving it as is will be easiest for everyone
already familiar with OE from other work.

I’d like to confirm with you that this is how the API can look like
before I make a PyPI release and add a full integration example on the blog.

If you’d like to use it, the best way is to

  • install openerplib using pip
  • git clone zato-labs
  • symlink both to zato_extra_paths, for instance

$ ln -s /usr/local/lib/python2.7/dist-packages/openerplib
/path/to/zato_extra_paths

$ ln -s ~/projects/zatosource-zato-labs/openerp-client/code/src/zato
/path/to/zato_extra_paths

  • configure Redis, for instance, if your connection is ‘my-oe-instance’,
    add these keys and values to Redis, substituting where it’s needed

zato:openerp:conn-info:hostname:my-oe-instance localhost
zato:openerp:conn-info:database:my-oe-instance behave
zato:openerp:conn-info:port:my-oe-instance 6079
zato:openerp:conn-info:login:my-oe-instance admin
zato:openerp:conn-info:login:password:my-oe-instance admin

Naturally, none of that will be required in the full release and a GUI
will be used to configure connections.

I’d also like to ask you about one OE-specific thing, I’m sure you’ll
know much more about it than me.

Empty passwords - right now the password is always required - should it
really be? Is it possible for OE users not to have passwords? If so,
from XML-RPC’s point of view, should an empty string be provided?

What do you think about it all?

many thanks,

On 21-07-13 18:49, Dariusz Suchojad wrote:

Empty passwords - right now the password is always required - should
it really be? Is it possible for OE users not to have passwords? If
so, from XML-RPC’s point of view, should an empty string be provided?

Hi Dariusz,

OpenERP explicitely forbids access with an empty password. I hope that
answers your question.

Keep up the good work!

Cheers,
Stefan.

On 07/21/2013 07:49 PM, Stefan Rijnhart wrote:

OpenERP explicitely forbids access with an empty password. I hope that
answers your question.

Thanks Stefan, this answers it perfectly :slight_smile:

I’ll wait some time for other comments, if any, and I’ll blog about it
with some broader usage examples.

many thanks again,