I am new to WSO2 so I just want to make sure I understand it all before I go down the rabbit hole. We currently have a Workflow System that uses very complex data validation input screens. We use the Oracle Workflow engine as the state engine (20 years old version of BPMN). We want to replace it with BPMN. I did read that you are able to interface with the BPMN process via REST. So I just want to make sure that we will be able to still use our complex screens and interface with the BPMN process where we have Human Tasks to do.
So basically I want our external application do all the data validation on user input data, once it is happy with the data it will save it to the database and then start a new instance of the BPMN process. We should set process variables required to do automatic routing by the BPMN process also via the REST interface.
When we have an approval to do the BPMN process will wait at the Human Task in the process until we tell it to follow a certain transition via a REST interface.
Will this be possible ?
The short answer is Yes, you can pretty much manage every step of the process through the REST API's that are provided.
For example you can start a process by message, where you send the message required to start a process to the API. So in your example, after validating the user input you can compose the right message and send it to the API to start the process.
Related
I have written some code that calls an executable and passes arguments to it via the cmd line.
For example it will call
my_process.exe -A my_argument
What I want to happen is that my program my_process will always be running looking for user input and instead of creating a new instance of the process I am wanting to write my data/arguments to the existing process.
I understand that how I am passing the parameters will change from the the initial process start (argc, argv) vs when using stdin.
I also know that I will have to change how I am calling the process but I am unsure of what I need to look into to get this done.
EDIT: so what I am trying to accomplish by doing all of this is below:
Website >> Web Service API >> Hardware API >> PLC
The website is on server A, the web Service and Hardware API is on Server B
OS is Windows 10 Pro 64bit
PLC is a programmable logic controller
The website will send a post to my webservice. The webservice will call the Hardware API which in turn will write or read data to the PLC.
This works when doing a single POST. But when doing multiple POSTS if the connection from the Hardware API to the PLC is still open it will fault.
The Connection between the Hardware API and the PLC is like a COM port not like a socket (which is misleading based on the programming manual).
So what I was trying to do was to keep my Web API the same but create another process that will take all the results from the Web API and put them in a FIFO and then pop them off to the Hardware API (which I will always have running and will have a persistent connection to the plc).
So really the Hardware API would always be running and be a single process that gets data passed to it. The Queue service would always be running and the Web API would pass the results over to it.
I have looked into the below:
https://www.boost.org/doc/libs/1_37_0/doc/html/interprocess.html
child/parent process/fork/file descriptors/dup/dup2
Any thoughts or advice is greatly appreciated.
I am trying to use an UWP app service to provide some non-UI processing service to other app including the host app. For responsiveness, I want to return the result progressively. Think about grep-ping a folder for files containing a certain string: It would be better to report the files as we found it instead of reporting everything at the end.
So my question is: Can this scenario be achieved with the current UWP technology? (I think it is probably possible via polling using the multiple app instances approach. I want to know if there's an easier method with app service.)
The AppServiceConnection is a bi-directional communication pipe, so you can use it to communicate progress updates from the service to the client. No need for polling. Just retain a reference to the AppServiceConnection instance in your service implementation once the client has connected and then call SendMessageAsync to send progress updates to client whenever you want.
I am developing a Windows Phone app where users can update a list. Each update, delete, add etc need to be stored in a database that sits behind a web service. As well as ensuring all the operations made on the phone end up in the cloud, I need to make sure the app is really responsive and the user doesn’t feel any lag time whatsoever.
What’s the best design to use here? Each check box change, each text box edit fires a new thread to contact the web service? Locally store a list of things that need to be updated then send to the server in batch every so often (what about the back button)? Am I missing another even easier implementation?
Thanks in advance,
Data updates to your web service are going to take some time to execute, so in terms of providing the very best responsiveness to the user your best approach would be to fire these off on a background thread.
If updates not taking place (until your app resumes) due to a back press is a concern for your app then you can increase the frequency of sending these updates off.
Storing data locally would be a good idea following each change to make sure nothing is lost since you don't know if your app will get interrupted such as by a phone call.
You are able to intercept the back button which would allow you to handle notifying the user of pending updates being processed or requesting confirmation to defer transmission (say in the case of poor performing network location). Perhaps a visual queue in your UI would be helpful to indicate pending requests in your storage queue.
You may want to give some thought to the overall frequency of data updates in a typical usage scenario for your application and how intensely this would utilise the network connection. Depending on this you may want to balance frequency of updates with potential power consumption.
This may guide you on whether to fire updates off of field level changes, a timer when the queue isn't empty, and/or manipulating a different row of data among other possibilities.
General efficiency guidance with mobile network communications is to have larger and less frequent transmissions rather than a "chatty" or frequent transmissions pattern, however this is up to you to decide what is most applicable for your application.
You might want to look into something similar to REST or SOAP.
Each update, delete, add would send a request to the web service. After the request is fulfilled, the web service sends a message back to the Phone application.
Since you want to keep this simple on the Phone application, you would send a URL to the web service, and the web service would respond with a simple message you can easily parse.
Something like this:
http://webservice?action=update&id=10345&data=...
With a reply of:
Update 10345 successful
The id number is just an incrementing sequence to identify the request / response pair.
There is the Microsoft Sync Framework recently released and discussed some weeks back on DotNetRocks. I must admit I didnt consider this till I read your comment.
I've not looked into the sync framework's dependencies and thus capability for running on the wp7 platform as yet, but it's probably worth checking out.
Here's a link to the framework.
And a link to Carl and Richard's show with Lev Novik, an architect on the project if you're interested in some background info. It was quite an interesting show.
I am wanting to write some web services using WCF.
I would like to have a "thread pool" in my web service.
For example, I have nearly 6gb of data I need to manipulate.
I would like the client to call an operation on the webservice and have a new task or thread created. The client is able to call a ListRunningTasks(); and have the webservice return a list of tasks. The client should be able to forcefully kill a task if it is taking too long e.g. KillTask(int taskID); or something. I have previously done some threading, but not inside WCF or a service that doesn't have state. Is this possible? If so, how would one go about implementing such a thing? Any reading, links or suggestions would be great.
Thanks, Mike.
One possible solution:
Implement explicit queues for your outstanding tasks taking into consideration that they take that long (20-30mins as you wrote).
Build a custom component to manage those queues e.g. you might even want capabilities to persist them, resume work when you restart the service etc.
Have explicitly created worker threads that pickup work from those queues.
Implement a WCF service to make your queue manager available to external systems.
Thread pools are more designed to process a high volume of short-running tasks.
You should consider using Windows Workflow Foundation to create such services. A state machine workflow can be exposed as a service in such a way that when method A is called, it will start the workflow (task), after which methods can be called to stop, suspend, or query the running task. WF will handle the state transitions, preventing illegal state changes, and making sure that new tasks are only spun up as necessary.
Note that WF will handle the threading issues for you in an almost transparent manner.
We currently use LoadRunner for performance testing our web apps, but we also have some server side processes we need to test.
Background:
We call these processes our "engines". One engine receives messages by polling an IBM WebSpere MQ queue for messages. It takes a message off the queue, processes it, and puts the result on an outbound queue. We currently test this engine via a TCL script that reads a file that contains the messages, puts the messages on the inbound queue, then polls the outbound queue for the results.
The other engine receives messages via a web service. The web service writes the message to a table in our database. The engine polls the database table for new messages, takes a message and processes it, and puts the result back into the database. We currently test this engine via a VBScript script that reads a file that contains the messages, sends the message to the web service, then keeps querying the web service for the result unitl it's ready.
Question:
We'd like to do away with the TCL and VBScript scripts and standardize on LoadRunner so that we have one tool to manage all our performance tests.
I know LoadRunner supports a Web Services protocol "out of the box", but I'm not sure how to use it. Does anyone know of any examples of how to use LoadRunner to test a web service?
Does LoadRunner have a protocol for MQ? Is it possible to use a LoadRunner Vuser to drive load (put messages) into an MQ queue? Would we need to purchase something from HP or some other vendor to do this?
Thanks :)
There is an add-in for LoadRunner in the incuded software to interface with MQ series and put the messages directly on the queue. Web services are fully supported also, and VBScript is supported too,perhaps using QTPro for the script and a GUI user in LoadRunner?
Colin.
For #1, as an alternative to a Web Services script, you could try recording a Windows Sockets script. I've used LoadRunner to record winsock scripts to test some (Java) APIs. What I did was write a really simple Java API client and then execute that from a Windows batch file. The batch file would then be referenced as the executable when recording a LR script in VUGen.
I'm not sure if VUGen can load a VBScript file for recording, but you might try. Otherwise, you might try wrapping your VBScript in a batch file that can be run by VUGen.
When VUGen records a winsock script, it's basically monitoring the network communication for the process you're recording with. After you're done recording, it'll generate a dump of the network data in a "data.ws" worksheet that you can look at and edit with VUGen. You can parameterize this data worksheet for your load tests.
One can code SOA requests and parse responses within LoadRunner.
See wilsonmar.com/1lrscript.htm.
But bear in mind that TCL and VBScript developed for functional testing have a different architecture and scope than LoadRunner scripts. QTP and WinRunner take over the application.
LoadRunner scripts focus on the exchange of data across the wire. In the case of headless SOA XML, this architectural distinction doesn't matter.
However, it may be easier for you to maintain VBscript from the GUI, because creating SOA scripts in LoadRunner require a deeper understanding of message formats than what most MQ developers have.
You really have three paths for pushing and popping messages off of an MQ queue using LoadRunner
(1) MQTester. This is a native MQ Protocol Add in for use with LoadRunner
(2) Winsock. Winsock development is best described as tedipously similar to picking fly scat out of ground pepper. Tedious, but in the end very rewarding. Out of the box, no additional add ins are required except license updates (possibly)
(3) JMS using a Java Virtual user, see. http://en.wikipedia.org/wiki/Java_Message_Service . You wind up with a small Java program in the Java template virtual user for LoadRunner. You will have to deal with all of the Java black magic aspects associated with LoadRunner, but once you nail down the combination of release and installation details you can use the virtual same code to post to just about any JMS provider (not just MQ) with some connection factory settings changed.
You should be able to do JMS with the web services virtual user as well, but I have not tested that configuration. Look at the JMS section of the run time settings.