wrapper.app.parameter.1=flux.Main

To use a secured engine rather than unsecured, you’ll want to make sure that you log in to the engine before creating / starting it in the code, like:

LocalSecurity localSecurity = factory.makeLocalSecurity();
localSecurity.login(engine, “admin”, “admin”);
SecurityAdministrator securityAdministrator = engine.getSecurityAdministrator();

And you’ll also want to enable remote access to the engine by calling:

RemoteSecurity remoteSecurity = factory.makeRemoteSecurity(engineConfiguration, engine);

You’ll also want to make sure you log out of the engine after starting it / setting up the runtime configuration:

localSecurity.logout(engine);

Could we continue to use tanuki to expose the flux engine as a windows service? I assume we need only tweak the unsecured-flux-engine-wrapper.conf. Is the example valid for a secure flux engine as well (with a few minor tweaks)

The AbstractFluxTest.readFlowChartFFC() method above illustrates how to read a flow chart from a file on disk. Once loaded, the flow chart is available as a flux.FlowChart object. This allows you to access any triggers, actions, flows, etc. and modify them via the Flux Java API.

That’s easy. Now for the difficult part. What to change and what to change it to? For your case of a File Exist Trigger watching an FTP server, I would suggest using the embeddable 100% Java Apache FTP Server (http://mina.apache.org/ftpserver/). This will allow you to test as much of the Flux functionality as possible. Furthermore, if you use the Flux runtime configuration properties file to set your FTP server properties in the File Exist Trigger (like: ${runtime hostname}), then you don’t even need to modify the values via the Java API but rather just have a different runtime configuration file for the test and production environments (i.e., runtime-test.properties may point to localhost for the FTP server).

For mocking the REST Action, again I would suggest embedding an HTTP server that can return serve the HTML file and again use runtime configuration properties with different values for the test and production configurations. This will allow you to make sure Flux is invoking a REST service and returning the results correctly (albeit not the production REST server, but close).

And for the Process Action, again, I’d use the runtime configuration properties to reference a different script/batch file in the test and production environments.

If you’re not keen on my recommended approach.. an alternative is to use the Java API, after loading the flow chart, to replace the File Exist, REST Action, and Process Action properties with a Java Action that does the returns the expected result. This is doable, but probably not a trivial task (flows and runtime data maps could be difficult to deal with when swapping out triggers/actions for Java Actions). IMOHO, I don’t prefer this approach because it requires more modifications to the flow chart for testing purposes than my recommended approach.

We have tests that embed the Apache FTP Server and also an HTTP server with mock REST resources. I can provide code examples for that if you’re interested in pursuing the embedded mock server route. If you’re interested in that, just let me know how pressing it is for you and I’ll schedule some time to post some example code for you.

Is it possible to mock out certain actions or triggers? Let me go over a scenario

I have a flowchart that starts with a file exists trigger which waits for a file over ftp then that file is processed through a java action which would return 0 or 1 depending on the file being “good” or “bad”. If the file is good then we call a rest service to get some more information call a process action and end if the file is bad print a message on the console and end. Now to test this flowchart I want to mock out the following
1) File exists trigger such that instead of waiting on ftp I supply the file from the local machine.
2) Rest action so that instead of making a call to a webservice we supply a local xml file.
3) If lets say the process action takes an hour to complete mock it out as well

We would like to load the flowchart from the file system for the unit test and I am hoping to reuse most of the information on the flowchart e.g. flows, runtime datamaps, checkpoints etc.

This video is showcasing the performance of the web tier: HTML, CSS, JavaScript, and REST. Things like page/tab switching, pagination, etc. were a sluggish in older versions of the Operations Console. These web application performance problems are eliminated in Flux 7.10.

The Flux 7.10 Operations Console also utilizes a distributed cache to monitor the status of flow charts in the cluster. Flux 7.9 used to query the database directly for status of flow charts. Flux 7.10 shows the real-time status of flow charts without contacting the database. This could allow the Operations Console to perform faster than the engine.

We made a few architectural changes in Flux 7.10 to make it perform faster both on the engine side and Operations Console side. The performance gain for both over Flux 7.9 is tremendous.

Flux does not provide any way to monitor the performance of a Flux engine, short of throughput of flow charts. Performance for Flux means “how many of your business processes can be executed in a given time?”. This can be measured through the run history API on the engine.

1. What kind of cluster is this ?
2. Where can we look at the engine’s performance stats instead of the web console’s ? The web console is only as responsive as the engine. Is that right ?