guyom...@gmail.com
02. Interfacing with existing tools via web services
03. How to migrate existing tasks to the new scheduler,
04. Interfacing with cloud solutions,
05. Connection to our LDAP, With SSO capability,
06. Allow 3-tier architecture,
08. Centrally deployed and updated agents,
09. Launch a task following an event / trigger (file arrival, sending an email, etc.),
10. Allow the setting up of scenarios (chain of tasks),
11. Be compatible with virtual machines,
12. Visualize the state of the tasks as well as their result in a simple and centralized way,
13. Allow administration of the launch of tasks in a simple and centralized way,
14. Create launching subgroups to separate different types of tasks (technical, functional, etc.)
15. Which version of SQL server is compatible with the solution?
16. Avoid the use of plain text passwords
17. HA functionality
Dieter Stubler
Hi Guillaume,
welcome to our schedulix forum.
Let's dive into your questions.
01.
schedulix can start OS processes under UNIX/Linux and Windows Environments.
To run tasks in other systems (ETL, Databases, ...) those system have to
provide some API to run thoses tasks from a command line.
Typically one wrapper script for each different system has to be created to invoke tasks from a schedulix job.
02.
There is a simple webservice included with the Web GUI Application server.
It takes connect credentials and a schedulix command and returns the JSON result
03.
This highly depends on the scheduler you currently use.
If this sceduler can export parsable job definitions, writing a migration helper tool is possible.
We have done that in the past a few times already but there is always some manual work to do and a migration
will need a few days depending on the size of the system to migrate.
04.
We have already users running schedulix in AWS cloud.
From our point of view there is nothing special with schedulix installations in a cloud systems.
Just install server and agent on your cloud systems as needed.
05.
SSO with AD under Windows can be implemented out of the box when running servers under Windows.
Should be no big deal to implement that using Linux servers. We are going to test that in the near future.
06.
Please elaborate a bit more on what you mean with 3 tier architecture.
07.
No query with number 07 :-)
08.
Currently there is no central deployment and upgrade for agents.
Since agents do not have to be updated very often (sometimes for years) this currently is not a
high priority feature but we have it on our plan for future releases.
09.
schedulix will submit jobs/batches on time schedule events and triggers firing on job finish events and resource state changes.
Additionally the API provides a SUBMIT command to submit jobs on demand.
There is also a submit command line utility to do that using this API.
So any System which creates events can just use this function to submit jobs/batches.
10.
schedulix allows to define jobs (processes to execute) and batches containing batches and/or jobs,
Jobs and batches can be child of more than one parent (modular re usability).
This hierachy can be as deap as you want and contain an arbitrary amount of jobs.
Chaining happens to due dependencies defined between jobs and batches.
Triggering the submit of a job when another job finishes is also possible.
11.
Running schedulix in virtual machines is a common use case and there are no known problems on that.
12. & 13.
The schedulix Web GUI allows for comfortable monitoring and operating of all your submitted jobs and batches.
Also submitting jobs/batches on demand can be done using the Web GUI easily with a few mouse clicks.
14.
Please elaborate a bit more on what functionality you expect from a 'launching sub group'.
Since batches and jobs can be reused as a child of any number of parents and the hierarchical organization of job and
batch definitions in a folder structure, grouping jobs and batches should be possible in any way.
15.
schedulix is using JDBC to access the database and is using very basic SQL functionality only.
So any version of SQL server should fine as long it is not really ancient.
16.
Storage of plain passwords is avoided where ever possible.
17.
Since schedulix is storing any data in its RDBMS repository, this repository always is up to date with the state of the system.
You can kill -9 you schedulix server without any problems.
So, if your DBMS is HA capable schedulix can be setup HA too.
If your live system crashes just start a schedulix server on your spare
system accessing your HA Database repository and you are up again.
(Some setup of ip addresses and switching those from your life to the spare system has to be done anyway).
I hope I could answer most of your questions.
If you like we can also arrange a web meeting, to discuss your requirements and answer any left over question.
Just drop me a line if you are interested in this.
I wish you a nice weekend!
Regards
Dieter
guyom...@gmail.com
Please elaborate a bit more on what you mean with 3 tier architecture.
Dieter Stubler
So you can install the schedulix repository database on one of your SQL Servers and configure the JDBC url respectively.
Connections to the schedulix server can be configured to use SSL/TLS encrypted communication.