Your comments

Hi Surya,

We don't at the moment. Our core flow engine has been built around Windows Workflow Foundation. While we have discussed it, we don't have any immediate plans to create a Linux version.
It would be simple enough for us (or you) to build ESB connectors and tools to interface with specific equipment or services, to interact with on the bus. Our architecture can definitely handle this scenario.
Our architecture also makes it possible to commercialize these, if you are possibly interested in building the tools and connectors for resale.
Warewolf ESB already excels at doing this. You can very easily expose Stored Procedures in Warewolf as Warewolf endpoints, and use the endpoints to produce standard JSON or XML over HTTP or HTTPS for consumption,
or use a Stored Procs via a Warewolf endpoint to update a database.

One of the advantages of the Smart Endpoints / Dumb Pipes approach is that you end up with a totally standard interface via the microservices regardless of what the ESB is actually connected to on the bus.


Hi Justin,

Yes it can be done. But you need to wrap the VB DLL because VB compiles to unmanaged code.
The wrapper wraps the unmanaged DLL within a managed DotNET DLL.
Its a fairly straightforward process. CodeProject have an article and some source samples to help you along the way.

http://www.codeproject.com/Articles/154144/Using-Unmanaged-VB-Code-in-NET

The other key issue of importance is that Warewolf is an ESB, so we only work with objects that can be serialized, so your VB methods that you call from Warewolf need to return simple, serializable objects.

I hope this helps.
Hi Surya,


Can you please attach your installer log files to this ticket, or mail them to me at alpha@warewolf.io


You can find the files here:


C:\Users\[[user]]\AppData\Local\Temp

It will be the latest

Warewolf_*.log

Warewolf_*_ProductMSI.log

There are 2 logs from the install. If you don’t mind, can you please send them both through from your PC

Thanks for your help,

Robin

Hi Garrett,

There are a few mechanisms that you can use right now to accomplish what you want to without having to add an extra layer of complexity to Warewolf. We are currently looking at extending the ESB to include queues that will provide that functionality.

But right now in Warewolf, you can schedule microservices to run at any given interval, so you can currently use this for pushing or notifications.

The other mechanism that is available, if you want something immediate, is to use Warewolf for web hooks - either fired by Warewolf, or an external process firing a Warewolf microservice as a web hook (simply calling the URL). Both of these techniques can be used as event mechanisms.

There are cases that I have seen, where record inserts within SQL server fire a SQL trigger that in turn fires a Warewolf microservice as a web-hook.

Hi,

Yes. firstly Warewolf uses Active Directory natively for SSO authentication.

In terms of service governance, it is very simple to a build monitoring, logging and reporting layer into Warewolf.
Implementing real time monitoring and error handling with Warewolf is also simple. In fact, we regard it as a best practice in production system deployments.

Most of the tools within Warewolf have the ability to send an error report to a specified microservice if the tool fails - so for these - simply specify the microservice URL and send the error reporting messages.

For Monitoring metrics, you can build two simple embedded micro-services that you add at the start and end of the microservice. The first one sets the startup metrics values and the second one collates the metrics and either logs them or sends them to a central microservice for logging, and feeding into a monitoring platform like Kibana https://www.elastic.co/downloads/kibana for real time monitoring.

Warewolf can also be used to send notifications by email, IM, or SMS
Glad to be of assistance.Sorry about the delay.
Hi Kyle.

Here is a simpler way to get return values back from Warewolf that works:

The one thing I have done is to exclude the <Datalist></Datalist> input variable from the URL as it is not required in this case. I also added an onload reference to the body tag, to run the JavaScript method when the page loads,
If you were using JQuery you could get the method to run when JQuery initializes, but an event needs to be specified to fire the function in this case.

I hope this answers your question.

<html><head></head> 
<body onload="GetRoll()">
<h1>Dice Roll Example</h1>
<div id="dicediv"></div>

<script type="text/javascript">
//This function demonstrates how to use a standard JasvaScript function to execute a Warewolf workflow.
function GetRoll() {
var xmlhttp = new XMLHttpRequest();
xmlhttp.withCredentials = true; //Required to ensure that Warewolf Server correctly authenticates.

// Note : I am calling Dice%20Roll.json to return JSON
// If I wanted to return XML I would have called Dice%20Roll.xml
xmlhttp.open("GET", "http://localhost:3142/services/My%20Category/Dice%20Roll.json?&wid=28681805-a0df-4bea-8bdc-8afeca830454", true);
xmlhttp.onload = function(e) {
var data = xmlhttp.responseText // The data received from the workflow execution.
callback(data);
}
xmlhttp.send();
};

function callback(data)
{
// See http://www.w3schools.com/json/json_eval.asp for details on the JSON parser
var obj = JSON.parse(data);
document.getElementById("dicediv").innerHTML = "You rolled a " + obj.DiceRoll[0];
};

</script>
</body>
</html>



Hi Kyle,
This article :
http://community.warewolf.io/topic/530506-executing-warewolf-service-in-javascript/
might hold the answer. It describes another way to return data from a Warewolf micro service that accounts for security. By default windows runs in a user context, but that gets lost when Javascript calls are made.
Something else that you can look at is the security permissions for both the Warewolf server and the individual microservices. This article describes how to set up permissions.
http://community.warewolf.io/topic/516326-security/
This article describes how to set up public permissions.
http://community.warewolf.io/topic/563251-secuirty-public/

Also, you should really be serving this page via a Web Server. You can run it locally via a browser, but most browsers disable XMLHttpRequest() by default for security reasons. You can however override this in Chrome by starting Chrome in a mode that allows file access from files. like this:

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --allow-file-access-from-files
This may be acceptable for development environments, but little else. You certainly don't want this on all the time.