zatosource / zato Goto Github PK

When browsing a list of channels a service available on,

http://localhost:8183/zato/service/overview/zato.service.invoke/?cluster=1

there also needs to be added a list of scheduler's jobs the service is used by.

RESTful approach for API specifies API endpoint prefix (/api/1.0) with all objects sharing it and having different suffixes (/api/1.0/products, /api/1.0/orders, /api/1.0/users). To use such connections in Zato, I'd have to create many Plain HTTP outgoing connections for each of the objects that RESTful API of external system supports.

In case of service updates its API version (API endpoint path from /api/1.0 to /api/1.1) it would be necessary to update many connections created.

It would be good to be able to create API endpoint prefix as outgoing connection and be able to specify suffixes (/products, /orders, /users) in Service code (when using the connection).

As of now, API calls never return passwords.

It can be at times interesting to have access to them so a 'needs_password' boolean flag needs to be added to each of the following services:

• zato.security.get-list
• zato.security.basic-auth.get-list
• zato.security.tech-account.get-list
• zato.security.wss.get-list
• zato.definition.amqp.get-list

Also, don't forget about updating tests - running ./run-tests.sh will sure have a lot of failed assertions.

For now, returning passwords in clear text will suffice. In the future, client should be able to request that they be encrypted using a specified password. The client password itself needs to be encrypted too - the thing to consider is how best to encrypt the client password given that each server has its own pair of pub/priv keys.

In https://zato.io/docs/progguide/service-dev.html we have description of log_input and log_output methods of Service with following example.

from zato.server.service import Service

class MyService(Service):
    def handle(self):
        self.log_input("Let's find out what the input was")

When invoking it

$ zato service invoke ~/tmp/qs-1/server1 logbug.my-service

I'm getting following:

2013-06-01 00:04:41,213 - INFO - 9212:Dummy-14 - logbug.my-service:838 - 
  {u'impl_name': u'logbug.MyService', u'name': u'logbug.my-service', 
  u'cid': u'K071827140907995446911018073887895735499', 
  u'invocation_time': datetime.datetime(2013, 5, 31, 21, 4, 41, 213198), 
  u'job_type': None, u'data_format': u'json', u'slow_threshold': 99999, 
  u'request.payload': None, u'wsgi_environ': {}, u'environ': {}, 
  u'user_msg': "Let's find out what the input was", u'usage': 1, u'channel': u'invoke'}

I've expected user_msg to be in the start of log line (for easier log reading) and output would be similar to:

2013-06-01 00:04:41,213 - INFO - 9212:Dummy-14 - logbug.my-service:838 - 
  Let's find out what the input was: {u'impl_name': u'logbug.MyService', 
  u'name': u'logbug.my-service', u'cid': u'K071827140907995446911018073887895735499', 
  u'invocation_time': datetime.datetime(2013, 5, 31, 21, 4, 41, 213198), 
  u'job_type': None, u'data_format': u'json', u'slow_threshold': 99999, 
  u'request.payload': None, u'wsgi_environ': {}, u'environ': {}, u'usage': 1,
  u'channel': u'invoke'}

Seeing as things like #61 will happen from time to time we need a patch manager of some sort.

This can be as simple as putting up a static site that ./install/sh would call via rsync to receive latest patches. The patches would then be applied using standard UNIX tools.

This would mean we had patches and quick fixes without releasing new versions.

Naturally, this really needs to be for hot-fixes only.

Right now we have a mostly very cool data_table (as defined in common.js) feature which really simplifies frontend development.

This is good but model classes are one thing that kinda looks like it could be replaced with what Backbone.js can offer.

In general B.js looks nice, let's have a closer look at it.

When creating a channel with a path that is already in use, the error is not nicely caught. The admin page shows a full traceback with the SQLAlchemy stack and query.

Suggest to use verification-before-save with a nice popover, like when no security is selected.

my new service (my_service.py from the tutorial) is not picked up without a clear mention of why in the log.

Log (with DEBUG level) in https://dl.dropboxusercontent.com/u/6295578/server.log

PyPI is on a CDN now but it still is possible it will have hiccups so we need our own PyPI mirror hosting all the packages Zato needs.

Installation on Ubuntu Server 12.04.2 LTS failed with a message that it could not install setuptools. Looking into versions.cfg I found a pinned dependency:

setuptools = 0.6c12dev-r88846

But that's not a version that I found on the local setuptools repository. Changing the version spec to the latest model build that is available fixes the install:

setuptools = 0.6c12dev_r89000

The 'zato create cluster' command uses 'broker_host' and 'broker_port' twice - this should be removed.

This is trivial to fix - just remove two options superfluously appended to opts in zato.cli.create_cluster.Create.

zato create cluster [-h] [--store-log] [--verbose] [--store-config]
      [--postgresql_schema POSTGRESQL_SCHEMA] [--odb_password 
      ODB_PASSWORD] [--tech_account_password TECH_ACCOUNT_PASSWORD]
      odb_type odb_host odb_port odb_user odb_db_name
      lb_host lb_port lb_agent_port 
      **broker_host** **broker_port** cluster_name
      broker_host broker_port tech_account_name

I created a scheduler task with "cron like" syntax , and when I delete it, it isn't deleted and the server show this error:

013-06-11 16:24:18,778 - INFO - 17140:Dummy-12 - zato.service.invoke:22 - cid:[K051876686377722151222066903251024634859], name:[zato.service.invoke], SIO request:[{u'name': u'zato.scheduler.delete', u'data_format': u'json', u'payload': u'eyJjbHVzdGVyX2lkIjogIjEiLCAiaWQiOiAiNDUxIn0=\n', u'channel': u'invoke', u'async': False, u'id': None, u'transport': None, u'expiration': 15}]
2013-06-11 16:24:18,792 - ERROR - 17140:Dummy-12 - zato.server.connection.http_soap.channel:171 - Caught an exception, cid:[K051876686377722151222066903251024634859], status_code:[500], format_exc:[Traceback (most recent call last):
File "/home/aaa/zato/code/zato-server/src/zato/server/connection/http_soap/channel.py", line 142, in dispatch
self.simple_io_config, data_format, path_info)
File "/home/aaa/zato/code/zato-server/src/zato/server/connection/http_soap/channel.py", line 262, in handle
worker_store, cid, simple_io_config, service_info=service_info, wsgi_environ=wsgi_environ)
File "/home/aaa/zato/code/zato-server/src/zato/server/service/init.py", line 588, in update_handle
service.handle()
File "/home/aaa/zato/code/zato-server/src/zato/server/service/internal/service.py", line 266, in handle
response = func(id, payload, channel, data_format, transport, serialize=True)
File "/home/aaa/zato/code/zato-server/src/zato/server/service/init.py", line 609, in invoke
return self.invoke_by_impl_name(self.server.service_store.name_to_impl_name[name], _args, *_kwargs)
KeyError: u'zato.scheduler.delete'
]

When the timezone is UTC (or any such like) and it's precisely midnight, the following exception is raised

ValueError: stop and start must be at least [3] minutes apart, start must be farther in past; start:[2012-11-29T00:00:00], stop:[2012-11-29T00:00:37.180146]

Technically, it is correct, but it should be somehow handled gracefully by the Zato admin,

As of now, one can run 'zato -h' in order to get a help for the 'zato' command but there is no actual 'zato help' command. This should be added and should simply return the same thing 'zato -h' does.

In web admin, changing the account's active flag from True to False doesn't seem to work. On refreshing the page, the checkbox is lit again.

[EDIT]

Installing Zato under Mac - https://zato.io/en/docs/3.2/admin/guide/install/mac.html

If hot-deployed code with Syntax Error is uploaded to server (via pickup-dir) the error is logged to logs, and that is normal. However rebooting server after that makes that server fail on startup (with Syntax Error in logs) thus making impossible to hot-deploy corrected code to this server. Deployment corrected code to other server doesn't help since server does not reach point when it can accept hot-deployed code, and does not sync hot-deploy state from other servers (See #56).

A small issue but it held me up for a while. Loadbalancing examples all balance to localhost. Would be reassuring to see one that balances out remotely. I understand remote server requires zato binaries so it would help to make that clear too.

When hot-deploying, services are distributed amongst live servers. In case new server boots up, it won't have hot-deployed services. It would be good for server to sync its hot-deploy state from other servers that cluster consist of.

I get this tb at step number 7

zato quickstart create ./qs-1 postgresql localhost 5432 zato1 zato1 localhost 6379 --verbose

ODB database password (will not be echoed):
Enter the odb_password again (will not be echoed):

Key/value database password (will not be echoed):
Enter the kvdb_password again (will not be echoed):
[1/8] Certificate authority created
[2/8] ODB schema already exists
[3/8] ODB initial data created
[4/8] server1 created
[5/8] server2 created
[6/8] Load-balancer created
Traceback (most recent call last):
  File "/Users/seletz/develop/python/zato/zato-1.1/bin/zato", line 89, in <module>
    sys.exit(zato.cli.zato_command.main())
  File "/Users/seletz/develop/python/zato/zato-1.1/zato-cli/src/zato/cli/zato_command.py", line 227, in main
    return run_command(get_parser().parse_args())
  File "/Users/seletz/develop/python/zato/zato-1.1/zato-cli/src/zato/cli/__init__.py", line 164, in run_command
    command_class[args.command](args).run(args)
  File "/Users/seletz/develop/python/zato/zato-1.1/zato-cli/src/zato/cli/__init__.py", line 358, in run
    sys.exit(self.execute(args))
  File "/Users/seletz/develop/python/zato/zato-1.1/zato-cli/src/zato/cli/quickstart.py", line 312, in execute
    admin_created = create_web_admin.Create(create_web_admin_args).execute(create_web_admin_args, False, password)
  File "/Users/seletz/develop/python/zato/zato-1.1/zato-cli/src/zato/cli/create_web_admin.py", line 99, in execute
    self.copy_web_admin_crypto(repo_dir, args)
  File "/Users/seletz/develop/python/zato/zato-1.1/zato-cli/src/zato/cli/__init__.py", line 375, in copy_web_admin_crypto
    shutil.copyfile(os.path.abspath(getattr(args, attr)), file_name)
  File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: u'/Users/seletz/develop/python/zato/qs-1/web-admin/qs-1/ca/out-pub/web-admin-pub-2013-06-18_21-50-28.pem'

this is on OSX 10.8. Tried with both zato 1.1 and 1.0.

I'm trying to install zato into a Centos 6.4 but it fails with this error:

django.db.models.loading: module references file
Got Django 1.3.1.
Getting distribution for 'django-debug-toolbar-django13==0.8.4'.
Got django-debug-toolbar-django13 0.8.4.
Getting distribution for 'django-settings==1.3-beta'.
Traceback (most recent call last):
File "", line 1, in
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 1712, in main
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 1700, in with_ei_usage
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 1716, in
File "/usr/lib64/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib64/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/usr/lib64/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 211, in run
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 427, in easy_install
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 476, in install_item
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 655, in install_eggs
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 930, in build_and_install
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/easy_install.py", line 919, in run_setup
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/sandbox.py", line 62, in run_setup
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/sandbox.py", line 105, in run
File "/root/zato/code/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/sandbox.py", line 64, in
File "setup.py", line 5, in
File "/tmp/easy_install-9Vu0Si/django-settings-1.3-beta/django_settings/init.py", line 8, in
#
File "/tmp/easy_install-9Vu0Si/django-settings-1.3-beta/django_settings/api.py", line 4, in
File "/tmp/easy_install-9Vu0Si/django-settings-1.3-beta/django_settings/dataapi.py", line 7, in
File "/tmp/easy_install-9Vu0Si/django-settings-1.3-beta/django_settings/lazyimport.py", line 2, in
ImportError: No module named importlib
An error occurred when trying to install django-settings 1.3-beta. Look above this message for any errors that were output by easy_install.
While:
Installing zato.
Getting distribution for 'django-settings==1.3-beta'.
Error: Couldn't install: django-settings 1.3-beta

OK

importlib isn't installed before django-settings

As of now, the configuration repository uses bzr which is quite cool and has a nice Pythonic API. It's understood that other VCS could be used so we should perhaps employ a tool like http://www.ros.org/doc/api/vcstools/html/ in order to insulate Zato from the particular repository implementation.

There needs to be a change password form in Zato admin in addition to the CLI so that users can change their own passwords - and no one else's. Changing other people's passwords will still require using the CLI.

It appears users attempt to start a quickstart cluster without first making sure Redis and SQL DB are configured properly.

Quickstart's script should first attempt to connect these DBs prior to starting any servers.

There is already zato.service.get-by-name API service but it would be convenient if there were a zato.service.get-by-id one.

This would work exactly the same manner except it would accept a service's ID on input.

At the moment (v1.0) all HTML pages that are generated by Zato Web UI have "Zato" as HTML title. It makes difficult to navigate through browsing history (in case there is need for several-step back or forward jump.

Something as simple as Serices - Zato, Plain HTTP outgoing connections - Zato, etc. would work. More advanced implementation would include search filter, service being viewed and the specific view of the service (Overview, Ivoker, Source code, etc.)

The odb_port parameter is ignored when creating an ODB - this should be fixed. zato.common.odb's engine_def should take port into account and all the places it's used in should pass it along.

It would be good if files from pickup-dir would be picked up not only when server is up, but also on server startup.

http://mqtt.org

There will shortly be a Python client for MQTT (from the mosquitto project) donated to the Eclipse Paho project. That should be a good on-ramp.

As suggested on IRC by @myroslav, there should be 'zato restart' command added to the CLI.

This should simply be a 'zato stop && zato start' functionality wrapped under one command.

install.sh should invoke a DEB-based one or an installer as it's been patched in #41 or another one for RPM systems so that simply doing install.sh should work on every platform supported.

@fklosowski suggested in a private chat that Dropbox support be added in a future Zato version. This seems a good idea indeed.

https://www.dropbox.com/developers/core/setup#python

At the moment web UI is offering a ping to Plain HTTP outgoing connection that translates into HEAD request. Often API endpoints do not support HEAD requests, ability to specify GET/PUT/OPTIONS/other-http-method would be great. Visually it could be implemented as small Advanced icon besides "ping" link showing the dialog with method to invoke.

I get below on hitting http://localhost:8183/zato/service/?cluster=

(InternalError) current transaction is aborted, commands ignored until end of transaction block
'SELECT cluster.id AS cluster_id, cluster.name AS cluster_name, cluster.description AS cluster_description, cluster.odb_type AS cluster_odb_type, cluster.odb_host AS cluster_odb_host, cluster.odb_port AS cluster_odb_port, cluster.odb_user AS cluster_odb_user, cluster.odb_db_name AS cluster_odb_db_name, cluster.odb_schema AS cluster_odb_schema, cluster.broker_host AS cluster_broker_host, cluster.broker_port AS cluster_broker_port, cluster.lb_host AS cluster_lb_host, cluster.lb_port AS cluster_lb_port, cluster.lb_agent_port AS cluster_lb_agent_port, cluster.cw_srv_id AS cluster_cw_srv_id, cluster.cw_srv_keep_alive_dt AS cluster_cw_srv_keep_alive_dt \nFROM cluster ORDER BY name' {}

/home/vagrant/zato-1.0/eggs/SQLAlchemy-0.7.9-py2.7-linux-i686.egg/sqlalchemy/engine/default.py in do_execute, line 331

I get similar errors when I visit other pages.

git should be one of dependencies installed by install.sh

http://docs.picloud.com/queue.html

Zato server refuses to start after abrupt shutdown (server power loss).

The attempt to start server produces:

$ zato start ~/tmp/qs-1/server1/ --verbose
Server at /home/zatotest/tmp/qs-1/server1 is already running

This is cause by stale serverX/zdaemon/server-XXX.sock.

Removing the control socket manually let servers to start.

The documentation could give an example how to register an outgoing Soap connection with WSSE authentication.

When following file is dropped in pickup-dir as test_resppayl.py:

# Zato
from zato.server.service import Service

class Strip(Service):
    def handle(self):
        resp = """{"foo": "0", "bar": []}"""
        self.response.payload = resp

class AsIs(Service):
    def handle(self):
        resp = """{"foo": "0", "bar": []}"""
        self.response.payload = "?"+resp

And declared services are invoked via CLI, one is getting following results:

$ zato service invoke ~/tmp/qs-1/server1 test-resppayl.strip
0
$ zato service invoke ~/tmp/qs-1/server1 test-resppayl.as-is
?{"foo": "0", "bar": []}

Note: no SIO declared in services. The test-resppayl.strip is expected to return {"foo": "0", "bar": []} and it returns only the value of first item of interpreted JSON instead? Should the data be returned literally in both cases?

The default value of 2**32 seconds set for deployment_lock_expires is too much, this should be changed because 32-bit systems have problems with it.

The /zato/service/request-response UI is good for being able to inspect the requests and responses that pass the system.

The biggest problem with that UI, that it doesn't catch Invocations that failed. That is essential if one corrected the problem and would like to re-attempt the service invocation the request.

It would be great if the Web UI offered the possibility to see list of failed requests (possibly limited to reasonable last 10-20 requests), and be able to invoke the service once more (with exactly same parameters) after correcting the problem.

If the data is expected to persist not forever, but until server is restarted or until some preconfigured expiry duration (3 days would be enough to cover problems occurring during weekends), it's ok.

For debugging purposes, it'd be great if system caches the log messages associated with that CID (including traceback of the error). but it is just nice-to-have feature, not really important one, the only important is ability to retrieve payload of failed request.

At the moment I'm doing just self.log_input of the request, then when I happen to have issue, I locate the relevant traceback from log files, then copy the payload out of log, convert it to valid json (to be passed to zato invoke) correct the issue ins ources, do new hot-deployment and re-invoke the service.

Potentially the "Failed invocations" can be limited only to Invocations happening only though channels (not internal invocations), but it is yet to be evaluated, what works best.

Trying to install zato on ubuntu, following the tutorial here: https://zato.io/docs/tutorial/01.html, but I get traceback below.

Traceback (most recent call last):
File "bin/zato", line 91, in

File "/home/vagrant/zato-1.0/zato-cli/src/zato/cli/zato_command.py", line 217, in main
return run_command(get_parser().parse_args())
File "/home/vagrant/zato-1.0/zato-cli/src/zato/cli/init.py", line 163, in run_command
command_classargs.command.run(args)
File "/home/vagrant/zato-1.0/zato-cli/src/zato/cli/init.py", line 357, in run
sys.exit(self.execute(args))
File "/home/vagrant/zato-1.0/zato-cli/src/zato/cli/quickstart.py", line 304, in execute
admin_created = create_web_admin.Create(create_web_admin_args).execute(create_web_admin_args, False, password)
File "/home/vagrant/zato-1.0/zato-cli/src/zato/cli/create_web_admin.py", line 132, in execute
from django.contrib.auth.models import User
File "/home/vagrant/zato-1.0/eggs/Django-1.3.1-py2.7.egg/django/contrib/auth/models.py", line 7, in
from django.db import models
File "/home/vagrant/zato-1.0/eggs/Django-1.3.1-py2.7.egg/django/db/init.py", line 14, in
if not settings.DATABASES:
File "/home/vagrant/zato-1.0/eggs/Django-1.3.1-py2.7.egg/django/utils/functional.py", line 276, in getattr
self._setup()
File "/home/vagrant/zato-1.0/eggs/Django-1.3.1-py2.7.egg/django/conf/init.py", line 42, in _setup
self._wrapped = Settings(settings_module)
File "/home/vagrant/zato-1.0/eggs/Django-1.3.1-py2.7.egg/django/conf/init.py", line 87, in init
mod = importlib.import_module(self.SETTINGS_MODULE)
File "/home/vagrant/zato-1.0/eggs/Django-1.3.1-py2.7.egg/django/utils/importlib.py", line 35, in import_module
import(name)
File "/home/vagrant/zato-1.0/zato-web-admin/src/zato/admin/settings.py", line 105, in
db_data['ENGINE'] = 'django.db.backends.' + django_sqlalchemy_engine[db_type]
KeyError: u'postgres'

It appears, the django_sqlalchemy_engine doesn't recognise 'postgres'?

Right now sample requests and responses don't store any channel-specific data so it's possible to find out how exactly the given HTTP conversation looked like, what SOAP envelope has been used etc.

hotfixman.sh needs to be parametrized - current Zato version it deals with needs to be picked up from somewhere. External config file or not, not much difference as long as it's not hard-coded.

I've tried adding HTTP Basic Auth definition with username and without password for Outgoing Plain HTTP connection, and Zato Web UI refuses to change password to empty one with errors requiring an input: Both fields are required and need to be equal and This is a required field. Just for experiment I've tried putting space and the error was the same.

Any CLI or programmatic approach to overcome the v1.0 limitation?

Reported on IRC https://webchat.freenode.net/?channels=zato

install.sh, before doing apt-get install anything, should really run apt-get update first so there are no nasty surprises if some packages cannot be found.

This may happen if a local package repository is used and it doesn't contain all the packages Zato needs.

If one adds/modifies Dictionary entry on /zato/kvdb/data-dict/dictionary/ of web-admin the following error is in logs:

2013-06-04 02:07:53,916 - INFO - 9224:Dummy-85 - zato.kvdb.data-dict.dictionary.edit:22 - cid:[K131435394561131870982197202555370559375], name:[zato.kvdb.data-dict.dictionary.edit], SIO request:[{u'value': u'1', u'system': u'crm', u'key': u'customer:test', u'id': 3}]
2013-06-04 02:07:53,918 - ERROR - 9224:Dummy-85 - zato.server.connection.http_soap.channel:171 - Caught an exception, cid:[K131435394561131870982197202555370559375], status_code:[500], _format_exc:[Traceback (most recent call last):
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/connection/http_soap/channel.py", line 142, in dispatch
    self.simple_io_config, data_format, path_info)
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/connection/http_soap/channel.py", line 262, in handle
    worker_store, cid, simple_io_config, service_info=service_info, wsgi_environ=wsgi_environ)
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/__init__.py", line 585, in update_handle
    service.handle()
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/internal/service.py", line 266, in handle
    response = func(id_, payload, channel, data_format, transport, serialize=True)
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/__init__.py", line 606, in invoke
    return self.invoke_by_impl_name(self.server.service_store.name_to_impl_name[name], *args, **kwargs)
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/__init__.py", line 603, in invoke_by_impl_name
    self.cid, self.request.simple_io_config, serialize=serialize, as_bunch=as_bunch)
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/__init__.py", line 585, in update_handle
    service.handle()
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/internal/kvdb/data_dict/dictionary.py", line 74, in handle
    if self._validate_entry(item, id):
  File "/home/zatotest/src/zato/code/zato-server/src/zato/server/service/internal/kvdb/data_dict/dictionary.py", line 51, in _validate_entry
    raise ZatoException(self.cid, msg)
ZatoException: System and key may contain only letters, digits and an underscore, failed to validate [customer:test] against the regular expression \w+
]

However the error is not exposed on UI and mis-informed as success "Successfully updated the dictionary entry system:[crm], key:[customer:test], value:[1]".

It would be great to have some location in Quickstart cluster preconfigured for rapid development. Saving file there would distribute file just like server{1,2}/pickup-dir does, but won't remove it. That would let opening the file with editor, and just saving it, making it possible to see changes to service almost instantly after save, without the need for copying the file to pickup-dir.

Right now the only when to discover whether a connector is up or not is to ps -efl | grep amqp or in a similar manner.

This should be fixed.

Connectors should periodically publish a heartbeat message back on the broker so the services subscribed were able to update a given connector's state somewhere (Redis, ODB).

Then, when listing connectors of a given type (AMQP, WMQ etc.) the web admin should not only be given their current state but it should itself grab the latest updates in background so that when someone opens the page and keeps it for 10 minutes, once a minute (say) an AJAX call should update info regarding their states.