(Migrated) bug? or unfinished version?

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

hi, buddy

I am try to publish a message to 1 server.

so I wrote:

========================================
class CustomerHandler:
def handle(self,request,response,service):
msg = {
‘action’: SERVICE.PUBLISH,
‘service’: ‘zato.helpers.input-logger’,
‘payload’: dumps(request),
‘cid’: new_cid()
}
service.broker_client.invoke_async(msg)
response[‘ret’] = 'OK’
response[‘cid’] = service.cid

===========================================

but error occured. Here’s the log:

2014-11-18 18:08:02,109 - ERROR - 25446:Dummy-16852 - zato.server.base:22 - Could not handle broker msg:[Bunch(action=u’SERVICE.PUBLISH’, cid=u’K04ZAGE8DVNRXGXBY21GN35JVZ92’, msg_type=u’0001’, payload=u’{“cmd”: “reg”, “hello”: “kitty”, “man”: “girl”}’, service=u’zato.helpers.input-logger’)], e:[Traceback (most recent call last):
File “/opt/zato/2.0/zato-server/src/zato/server/base/init.py”, line 45, in on_broker_msg
action = code_to_name[msg[‘action’]]

I looked into the codes, It looks like a bug. and I am not sure how to fix it.

On 18/11/14 13:40, Kelvin wrote:

  def handle(self,request,response,service):

Hi Kelvin,

please attach, rather than sending it inline, the exact code reproducing
the behaviour.

The code you sent in is not a Zato service, it looks similar but it’s
not a service.

thanks,

On 18/11/14 13:40, Kelvin wrote:

  def handle(self,request,response,service):

Hi Kelvin,

please attach, rather than sending it inline, the exact code reproducing
the behaviour.

The code you sent in is not a Zato service, it looks similar but it’s
not a service.

thanks,

It’s service. I just gave them a little wrapper.

I will send you the whole source code.

I just can not use SERVICE.PUBLISH to publish messages.

if I use the invoke_async instead of, all the codes run well.

At 2014-11-18 21:04:20, “Dariusz Suchojad” dsuch@zato.io wrote:

On 18/11/14 13:40, Kelvin wrote:

  def handle(self,request,response,service):

Hi Kelvin,

please attach, rather than sending it inline, the exact code reproducing
the behaviour.

The code you sent in is not a Zato service, it looks similar but it’s
not a service.

thanks,

On 19/11/14 02:13, Kelvin wrote:

It’s service. I just gave them a little wrapper.

Hey, let’s keep it cool, friends :slight_smile:

Kelvin - the way you sometimes present your code is not very well suited
for the community mailing list.

Zato is a an open-source product and project with both commercial and
community support.

The idea is that you get the software for free including access to
product’s documentation. You go through the tutorial, usage examples and
generally, spent at least several days getting yourself familiar with
everything. And I know you did it because your code is not trivial.

When you need assistance on the mailing list, you need to remember that
people here really want to help each other. If you don’t know something
then someone else will know the answer.

The beauty of it all is that Zato is an integration platform so combined
people’s knowledge is very broad and spans various industries -
finances, ERP, health-care or telecommunications to name a few. But for
most of them, it’s not their paid job to read the list and answer the
questions.

Hence, when you need assistance, please make it easier for everyone by
providing self-contained usage examples exhibiting the behaviour you are
concerned with.

This is exactly what happened here below where it was me who was able to
pinpoint the issue as soon as I had the complete picture and the exact
commands to use:

https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2014-November/000673.html

https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2014-November/000677.html

I know it takes more time on your end but this is how the mailing list
works. For free, you get nice answers from nice people but you need to
be prepared for additional work on your side with preparing
self-contained examples that are ready for people to follow without
thinking what sort of wrappers they can be.

Now, if you don’t have time for it, you are encouraged to contact Zato
Source, the company offering commercial support
https://zato.io/support.html - that way me or my colleagues will be able
to, say, log into your environment and have a look at the code ourselves
without your spending any time on the issue.

But on the free community mailing list, please remember that people
willing to help you will need a bit more from you.

As for the bugs, they sure do happen so I’m not rejecting any idea of
your finding a real one but on the mailing list, in order for people to
confirm it whether it’s a genuine bug or not, you need to provide
self-contained usage examples that are easy for people to examine and
understand.

Thanks a lot and I’m sure we’ll resolve everything soon :slight_smile:

On 19/11/14 11:43, Kelvin wrote:

I just want to come here to discuss whether there is a hidden bug here?

Hi Kelvin,

it doesn’t seem so, nope.

Please have a look here:

https://gist.githubusercontent.com/dsuch/caf730130c9264b714a9/raw/43f2682d69ab479a448362ead5f251ae2575d236/mypub-log.txt

This is the code I used for publishing a message + a log entry it
produced. Everything looks fine.

If you are not on GitHub yet, consider opening an account so that in the
future you can post your code using gists:

https://gist.github.com/

That way it is easy to read and comment.

thanks,

Dear Coeuz:

I think there must be something misunderstanding.

First thing, I always respect the God who create ZATO very much . (I mean Darisuz)

Because of his work, I can build my things rapidly.

I am coming for help. And I hope I can make ZATO more stronger and contribute something to it.

I am not coming for arguing or anything impolite.

I am not a Latin language user, I am not good at English. so some times I can not describe the problem clearly and hardly know what the tutorial means.

In these days , I did read tutorial once and once again.

I wrote the sample code , and make it became the service.

Just like the tutorial tells me to do . (writes the code , and configure it in webadmin)

I would like to show all the code here ,but it’s not easy to post codes here.

OK, I will show all the codes below,.

======================customer_broker.py==========================

-- coding: utf-8 --

from future import absolute_import, division, print_function, unicode_literals

import sys
import traceback
from zato.common.util import new_cid
from json import dumps, loads
from zato.common.broker_message import SERVICE
from zato.server.service import Service

###################################################################

Here is the access.

This class is the wrapper

###################################################################

class CustomerBroker(Service):
def handle(self):
self.logger.info(‘Customer Broker is called! cid = [{}]’.format(self.cid))

response = {}
payload = self.request.payload
payload[‘org_cid’] = self.cid

try:

if payload[‘method’] == ‘async’:
self.invoke_async(‘customer-engine.customer-engine’,payload)
response[‘cid’] = self.cid
response[‘ret’] = 'OK’
else:
response = eval(self.invoke(‘customer-engine.customer-engine’,payload))
response[‘cid’] = self.cid

except Exception:
exstr = traceback.format_exc()
self.logger.error(’[{}] '.format(exstr))
response[‘cid’] = self.cid
response[‘ret’] = 'SYS ERR’
response[‘info’] = ‘system error’

self.response.payload = dumps(response)

===============================customer_engine.py=================================

-- coding: utf-8 --

from future import absolute_import, division, print_function, unicode_literals

import sys
import traceback
from json import dumps, loads
from zato.server.service import Service

SUPPORTED_CMDS={
“reg”: “CustomerReg”,
“upd”: “CustomerUpdate”
}

class CustomerHandler:
def handle(self,request,response,service):
service.logger.info(‘Base was called, cid = {},org = {}’.format(service.cid,request[‘org_cid’]))
response[‘ret’] = 'OK’
response[‘cid’] = service.cid

class CustomerReg (CustomerHandler):
def handle(self,request,response,service):
service.logger.info(‘Reg was called, cid = {},org = {}’.format(service.cid,request[‘org_cid’]))
response[‘ret’] = 'OK’
response[‘cid’] = service.cid

class CustomerUpdate (CustomerHandler):
def handle(self,request,response,service):
service.logger.info(‘Update was called, cid = {}, org = {}’.format(service.cid,request[‘org_cid’]))
response[‘ret’] = 'OK’
response[‘cid’] = service.cid

###################################################################

Here is the access. Engine starts

This class is to find situable class to handle

###################################################################

class CustomerEngine(Service):
def handle(self):
response = {}
request = self.request.payload

try:

cmd = request[‘cmd’]
for k,v in SUPPORTED_CMDS.items() :
if cmd == k :
handler = globals()[v] ()
handler.handle( request,response,self)
response = dumps(response)
self.response.payload = response
return
self.logger.error(‘NO CLASS found, CMD = {}, cid = {}, org= {}’ . format(cmd,self.cid,request[‘org_cid’]) )
response[‘cid’] = self.cid
response[‘ret’] = 'ERROR’
response[‘info’] = ‘unknown cmd’

except Exception:
exstr = traceback.format_exc()
self.logger.error(’[{}] '.format(exstr))
response[‘ret’] = 'SYS ERR’
response[‘info’] = 'Unknown ERROR’
response[‘cid’] = self.cid
response = dumps(response)
self.response.payload = response
===============================customer_engine.py=================================

These codes run well except when I used SERVICE.PUBLISH to replace invoke_async in CustomerBroker.handle function

Maybe I made stupid things, but I am working hard. I just can not understand the tutorial very well.

If I do anything impolite , please forgive me.

And I will apologize for anything impolite.

Thanks.

Your sincerely

Kelvin

At 2014-11-19 17:09:37, “Coeuz” coeuz@coeuz.net wrote:

El 19/11/14 a les 02:13, Kelvin ha escrit:

It’s service. I just gave them a little wrapper.

Whoa, whoa…keep down that arrogance, man.

If you had read something in the Zato tutorial
(https://zato.io/docs/tutorial/01.html) or in the developing
documentation (https://zato.io/docs/progguide/service-dev.html) instead
of jumping directly into the code you would have read that “a service is
a Python class that subclasses zato.server.Service and implements a
handle(self) method”.
This is NOT the case, so no, this is NOT a service no matter how hard
you want to give it that name.

And, please, read some of the documentation, understand it and follow
the tutorial before coming here claiming to having found a bug or
something partially implemented.

In that case, if you are not trying to teach the guy who created all
this zato story (I mean Darisuz) what is a service and what is not and
you are open to learn it yourself instead, be sure that everyone here
will be very glad to share their knowledge with you to help you achieve
your objectives.

Regards,
Carles

Dear Dariusz Suchojad:

 I am sorry for not describing things clearly.

I will do it better next time.

In this case, I am not coming for solution . I just want to come here to discuss whether there is a hidden bug here

So I just wrote something for short

I am sorry

At 2014-11-19 18:29:05, “Dariusz Suchojad” dsuch@zato.io wrote:

On 19/11/14 02:13, Kelvin wrote:

It’s service. I just gave them a little wrapper.

Hey, let’s keep it cool, friends :slight_smile:

Kelvin - the way you sometimes present your code is not very well suited
for the community mailing list.

Zato is a an open-source product and project with both commercial and
community support.

The idea is that you get the software for free including access to
product’s documentation. You go through the tutorial, usage examples and
generally, spent at least several days getting yourself familiar with
everything. And I know you did it because your code is not trivial.

When you need assistance on the mailing list, you need to remember that
people here really want to help each other. If you don’t know something
then someone else will know the answer.

The beauty of it all is that Zato is an integration platform so combined
people’s knowledge is very broad and spans various industries -
finances, ERP, health-care or telecommunications to name a few. But for
most of them, it’s not their paid job to read the list and answer the
questions.

Hence, when you need assistance, please make it easier for everyone by
providing self-contained usage examples exhibiting the behaviour you are
concerned with.

This is exactly what happened here below where it was me who was able to
pinpoint the issue as soon as I had the complete picture and the exact
commands to use:

https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2014-November/000673.html

https://mailman-mail5.webfaction.com/pipermail/zato-discuss/2014-November/000677.html

I know it takes more time on your end but this is how the mailing list
works. For free, you get nice answers from nice people but you need to
be prepared for additional work on your side with preparing
self-contained examples that are ready for people to follow without
thinking what sort of wrappers they can be.

Now, if you don’t have time for it, you are encouraged to contact Zato
Source, the company offering commercial support
https://zato.io/support.html - that way me or my colleagues will be able
to, say, log into your environment and have a look at the code ourselves
without your spending any time on the issue.

But on the free community mailing list, please remember that people
willing to help you will need a bit more from you.

As for the bugs, they sure do happen so I’m not rejecting any idea of
your finding a real one but on the mailing list, in order for people to
confirm it whether it’s a genuine bug or not, you need to provide
self-contained usage examples that are easy for people to examine and
understand.

Thanks a lot and I’m sure we’ll resolve everything soon :slight_smile:

Hi, dear all

I catch the point now.

I am a C++ coder, so I think SERVICE.PUBLISH to be a constant It is a basic data type but not a struct.

I copy these codes from https://zato.io/docs/progguide/service-dev.html#progguide-write-service-broker-client

So, I think it’s better to correct the documents so that no more man like me make the stupid things.

Thank you for your kindness.

Alex and Dariusz Suchojad

At 2014-11-19 21:11:52, “Dariusz Suchojad” dsuch@zato.io wrote:

On 19/11/14 11:43, Kelvin wrote:

I just want to come here to discuss whether there is a hidden bug here

Hi Kelvin,

it doesn’t seem so, nope.

Please have a look here:

https://gist.github.com/dsuch/599a140307d285f13d64

https://gist.githubusercontent.com/dsuch/caf730130c9264b714a9/raw/43f2682d69ab479a448362ead5f251ae2575d236/mypub-log.txt

This is the code I used for publishing a message + a log entry it
produced. Everything looks fine.

If you are not on GitHub yet, consider opening an account so that in the
future you can post your code using gists:

https://gist.github.com/

That way it is easy to read and comment.

thanks,

On 20/11/14 03:38, Kelvin wrote:

I am a C++ coder, so I think SERVICE.PUBLISH to be a constant。 It is
a basic data type but not a struct.

I copy these codes
from https://zato.io/docs/progguide/service-dev.html#progguide-write-service-broker-client

Yes, you are right that the documentation should be updated and it will
be done before 2.0 is released, you are reading docs for 1.1 right now.

By the way, out of curiosity - is there any particular reason why you
aren’t using self.invoke_async directly?

Good question.

Supposed that a customer pays for a on-site service( for example , cooking) . Now system has to do 3 things

  1. Notify the financial system that a service is paid, get the money

2.Arrange the staff to visit customer to provide service.

3.Mark the customer in CRM system

Maybe you’ll say ,it’s better to notify systems one by one. But I prefer doing all the things in parallel.

Because all these actions are independent.

So, To me, Publish or Broadcast is very important.

In my opinion , the Publish function Zato provided needs some improvement.

Refer to the document, the message is delivered to the service on all the server.

It seems that the function is more useful when doing system maintenance than doing business.( for example ,shutdown message? restart message? or something else)

SO , in this case . Zato can broadcast a message to several different service on the servers. One different service per server.

What’s your opinion?

BTW,
I coded publish function as you showed me , but only one log was written (2 servers).

not like the phenomenon you mentioned in document :https://zato.io/docs/progguide/service-dev.html.

===========================================

Note the data has been written out to logs twice because in this particular case the cluster consisted of two servers, each running one worker.

Visit the section on how to invoke only a single instance of a service if you don’t want all of your services to receive the message.

Any change in Zato 2.0?

Best wishes.

At 2014-11-20 23:23:23, “Dariusz Suchojad” dsuch@zato.io wrote:

On 20/11/14 03:38, Kelvin wrote:

I am a C++ coder, so I think SERVICE.PUBLISH to be a constant It is
a basic data type but not a struct.

I copy these codes
from https://zato.io/docs/progguide/service-dev.html#progguide-write-service-broker-client

Yes, you are right that the documentation should be updated and it will
be done before 2.0 is released, you are reading docs for 1.1 right now.

By the way, out of curiosity - is there any particular reason why you
aren’t using self.invoke_async directly?

On 21/11/14 04:43, Kelvin wrote:

SO , in this case . Zato can broadcast a message to several different
service on the servers. One different service per server.

What’s your opinion?

Sure, that’s a nice approach.

self.broker_client is meant for internal communication between services
and for business publish/subscribe 2.0 has the actual inter-systems
publish subscribe.

Check out the links below.



Here I defined a /customer/created topic to which two consumer systems
are subscribed and they can receive messages on that topic either by
polling it periodically or a callback URL can be registered for Zato to
deliver new messages to them as they arrive.

So if a third system, a producer, publishes a messages on the topic,
it’s automatically delivered to each system subscribed.

Consumers and producers use Zato’s REST services to send/receive
messages but they don’t communicate directly, this is all asynchronous.

Also, within your service, to publish a message to a topic you call a
single line …

self.pubsub.publish(‘My message’, ‘/my/topic’)

… and that delivers it where it needs to go, to all the subscribers.

There’s way more to pub/sub then listed above, you have messages queues,
including in-flight ones, you can set message properties, browse
messages set depths, publish messages from web admin and an API for
everything. This will be documented for 2.0 as well.

But when using self.invoke_async - can you just loop over all the
service names you’re interested in?

for name in ‘service1’, ‘service2’:
self.invoke_async(name, ‘My message’)

BTW,
I coded publish function as you showed me , but only one log was written
(2 servers).

This is because you are reading the docs for self.broker_client.publish
but you’re using self.broker_client.invoke_async.

That’s great.

As you know ,I am reading the Zato 1.1 document. So I don’t know this new feature.

That will be great using the Topic model.

I’ll try it.

I hope that the new 2.0 document will release soon. :slight_smile:

Thank you for your great work.