Client Application

Fuzible is packed with a background service and a Client application that allows any user to remotely launch a Job.

The Client Application is a simple tool that can be distributed to anyone (in your company, for exemple) to let them have a hand on some Jobs they would usually ask you to execute.

Some use cases :

• Someone would like to extract some data randomly during the month
• Someone needs to regularly integrate a file into a database, but the integration day and the filename are varying…)
• Someone wants to send a weekly reporting of some data

More globally, any task for which your added value (apart from clicking on a button) is very small

The background service relies on a stack system, in which any invoked Job is stacked and launched in order.

You can set the quantity of jobs executed simultaneously, and a priority for each Job. The stack system will take account of requested date and priority.

The background service is also responsible for the launch of orchestrated Jobs, who are also stacked to avoid collisions, multiple launchs and overflow.

Everything is thought to avoid network, disk, cpu and ram saturation

1. Allowing a Job to be available to Client Application Users

The background service and the Client App. are making use of a database to work. By default, Fuzible internal SQLite database is used but you are free to use anything else : Postgres, Mysql/MariaDB, Sql Server, SQLite, Oracle are compatible : otherwise, the only thing you have to care about is that the Client App. performs calls to that database ; the client machine must have the rights to do so.

2. The Client Application

2.1. Basic settings

For security reasons, everyone can see all the Jobs, but an user must know the password to invoke a Job launch.

Users can also choose to immediately stack a Job request or to delay it : for exemple, if he wants the Job to be executed at 2am, he won’t have to wake-up and launch the Client App !

They also can change the Dynamic Parameters : It’s very useful if the Job is, for exemple, a file integration, and the filename is only known by the user : the filename can be set as a dynamic parameters, and the query, wrote consequently (see here).

2.2. Requesting a Job Launch

There is a flood control system which prohibits the user to launch the same Job multiple times in a short frame of time. The “flooding delay” is also configurable.

2.3. Checking the Status