How we can create a manuall Task (adhoc Task) and assign it to a User when some actions are triggered (e.g. when the Service is called)?
Ad-hoc tasks run in the context of a BPD. What is the connection between the service you are calling and the Ad-Hoc task? Generally the ad-hoc events are meant to be triggered by a participant in the process selecting the item they want to launch.
If what you want is that an external system triggers an event in a running instance when certain things happen you might want to look at Intermediate Message Events (IMEs). To really provide the correct full answer we likely need to have a better understanding of the underlying use case in order to guide you well.
From your answer I am not able to find you doing it on BPD level or Service level.
If you are doing on BPD level then you can use intermediate event to call that Activity attached to that service.you can configure whether you want to fire that event or not on previous human service using UCA.
Related
I've got the task to talk about event based communicatoin and the publish/subscribe based communication in JavaScript.
After thinking about it I wonder that the CustomEvents in JavaScript actually use the publish/subscribe pattern.
Dispatching a CustomEvent is like publishing new data or triggering the update function in the subscribers and creating an event listener is the same es subscribing to a publisher.
In other words every time a event is thrown every listener's callback is run is just the same as every time a publisher publishes new data, the subscriber's update functions are called.
Is this a correct solution or did I not got the key concepts fo the two patterns?
I have a Javascript class that performs a number of validity checks using the data provided to the class. I am trying to figure out the best way to create a validate() function which would return one error or multiple errors. One way would be to return an array of errors. Another way would be to pass a delegate to the function which would fire whenever any error occurs. Another way would be to create an event that would be fired whenever any error occurs. Out of these 3, which would be the most appropriate for what I am trying to accomplish?
Returning an array makes the interface a bit complex. On the other hand, if I use a delegate or event, then the delegate function/event code could be a bit complex as well.
If I were going to be a user of your interface, then I'd like to be able to subscribe to certain subsets or levels of errors spat out from the object.
For example, lots of loggers out there act on the notion of a logging level (Verbose, Warning, or Error for example). You could provide an interface where your object is actually logging/pushing notifications for each type of error it encounters, but you expose different callbacks for each type of message. So your users will be able to decide what to listen to.
To answer your question though, I'd like to see all errors rather than just one. And I'd say keep them coming until I unsubscribe from the notifications.
It seems like Backbone.Radio provides 2 new abstractions - commands and requests. They're pretty much identical to Backbone.Events, except that they can have only 1 subscriber. Is that it, and if so what advantage do they provide over events?
I plan on using Backbone.Events/Radio with React.js, if that helps.
I have not actually used Backbone.Radio but do make extensive use of Backbone.wreqr https://github.com/marionettejs/backbone.wreqr which provides an almost identical command service.
In my usage the difference between events and commands is:
For events to work the sender and receiver of an event must both exist and have a reference to each other and the receiver must be in a position to deal with the event properly. This can often be problematic in a fully asynchronous browser environment where different parts of your application are running at the same time.
Commands allow you to decouple the sender and receiver. One object, lets say a View A, can simply send command 'update_user_details'.
My second Object View B sets up a command handler for 'update_user_details' which will change the user details on the screen.
But what if View B does not yet exist, or is not yet rendered. In the event listener pattern you would have to make sure View A exists, that it passes a reference to itself to View B and then you attach an event listener in View B.
With commands it is not a problem, View A sends a command, if no-one has set a handler then nothing bad happens, the command just does nothing.
When View B turns up, totally independent of View A, it sets a handler and will respond to all future commands.
Just a final note about intent:
The event pattern can be thought about in this way: I, View A have just done something, anyone that is interested (the event listeners) can do what they like about it, I View A don't care what you do.
In the command pattern: I View A want someone to do something, I don't care who does it, I just want it done right.
Channels. The key difference with Backbone.Radio over plain vanilla Backbone.Events that I have seen is that it allows you to setup channels to which your code can 'tune in' e.g. from the documentation:
var userChannel = Backbone.Radio.channel('user');
This means that logical functions or apps in your code can emit and handle events only on a specific channel - even if you emit events with the same name, if they're on different channels you won't get cross-contamination. This ties in nicely with the principles behind separation of duties in your code.
The other other difference, and IMHO it's subtle, more to do with elegance of coding than any real functionality difference, is that if you're telling something to respond to an event then it's really a Command, and Backbone.Radio allows you to separate these kinds of event into that type. Similar logic applies to the Requests type.
For completeness...
The docs also explain that a Channel is an object that has all three types of messages (Events, Commands and Requests) mixed in. You mix it into an object (I use Marionette so I'm mixing into an instance of Marionette.Object) using Underscore/Lo-Dash's .extend():
_.extend(objectToBeExtended, Backbone.Radio.Requests);
And the same for Commands of course. The syntax for events is different as that's baked into Backbone itself so the second parameter is just Backbone.Events.
I am making a computer system which I have broken down into several smaller parts.
From a given experience, it is crucial in software development to keep systems small.
In order to do that I am implementing a module which serves a specific purpose, all and by itself without having any idea what the rest of the system is doing. (ideal)
So this module goes there and does its thing, and when an event occurs in an instance of this module, I want the index file to become aware of that happening.
I do not want this module to communicate directly to the other modules, as they should not communicate with each other, thereby decreasing dependencies within the system.
Now, I have made the instance and the instance does everything right,
but when an event occurs in this instance, how do I get that information over to the index file?
An event of this instance is implemented in the following manner:
the_div.addEventListener('mousedown',this.react_to_mouse_down_function);
And here its a question how its best to get this happening to the index file, I can do in the index file:
the_div.addEventListener('click', the_function);
but that forces the index file to be aware of things going on in the instance because
the instance has children which each has event detector and their numbers can grow and shrink and god knows what.
It would be best if the index file wouldn't need to understand how the instance of the module works, and thereby not needing to be generating new event listeners on the fly as the instance is living.
How is it best to setup the interaction between the index file and this instance?
This sounds like a pub/sub problem. This would let the module publish a specific custom event when state changes and the index (or any other module) can subscribe to that event if needed. The module does not communicate with anything besides the pub/sub controller.
Here is a good link:
http://addyosmani.com/resources/essentialjsdesignpatterns/book/#observerpatternjavascript
I find myself referring to various sections of this page often.
The solution I came to was to have a designated module called 'messages', and it takes care of receiving event driving messages from instances.
An instance of the message module is made global and named 'imessages'. And each module, when an event within it occurs, checks if it has access to the global 'imessage' object, and if it does and the imessage object contains a function with the same name as the given event, it calls that function and sends relevant information as arguments.
The given message function is now defined in the index file in a designated message module, relieving this module of any further interaction with the outside world.
Modules with this functionality need now not communicate with any other concrete modules. Just the index file.
It just needs to be stated in the API of each module applying this, how this dependency decreasing functionality of it works.
I have a basic express server that needs to store some global variables during each request handling.
More in depth, request handling involves many operation that need to be stored in a variable such as global.transaction[]
Of course if I use the global scope, every connection will share information of its transaction and I need a global scope because I need to access the transaction array from many other modules, during my execution.
Any suggestion on this problem? I feel like is something very trivial but I'm looking for complicated solutions :)
Many thanks!
UPDATE
This is a case scenario, to be more clear.
On every request I have 3 modules (ModuleA, ModuleB, ModuleC) which read the content of 10 random files in one directory. I want to keep track of the list of file names read by every request, and send back with res.write the list.
So ModuleA/B/C need to access a sort of global variable but the lists of request_1, request_2, request_3 etc... don't have to mix up.
Here is my suggestion avoid global state like fire.
It's the number one maintenance problem in Node servers from my experience.
It makes your code not composable and harder to reuse.
It creates implicit dependencies in your code - you're never sure which piece depends on which and it's not easy to verify.
You want the parts of code that each piece of an application uses to be as explicit as possible. It's a huge issue.
The issue
We want to synchronize state across multiple requests and act accordingly. This is a very big problem in writing software - some say even the biggest. The importance of the way objects in the application communicate can not be overestimated.
Some solutions
There are several ways to accomplish sharing state across requests or server wide in a Node server. It depends on what you want to do. Here are the two most common imo.
I want to observe what the requests do.
I want one request to do things based on what another request did.
1. I want to observe what the requests do
Again, there are many ways to do this. Here are the two I see most.
Using an event emitter
This way requests emit events. The application reads events the requests fire and learns about them accordingly. The application itself could be an event emitter you can observe from the outside.
You can do something like:
request.emit("Client did something silly", theSillyThing);
And then listen to it from the outside if you choose to.
Using an observer pattern
This is like an event emitter but reversed. You keep a list of dependencies on the request and call a handler method on them yourself when something interesting happens on the request.
Personally, I usually prefer an event emitter because I think they usually solve the case better.
2. I want one request to do things based on what another request did.
This is a lot tricker than just listening. again, there are several approaches here. What they have in common is that we put the sharing in a service
Instead of having global state - each request gets access to a service - for example when you read a file you notify the service and when you want a list of read files - you ask the service. Everything is explicit in the dependency.
The service is not global, only dependencies of it. For example, it can coordinate resources and the data, being some form of Repository).
Nice theory! Now what about my use case?
Here are two options for what I would do in your case. It's far from the only solution.
First option:
Each of the modules are an event emitter, whenever they read a file they emit an event.
A service listens to all their events and keeps count.
Requests have access to that service explicitly and can query it for a list of files.
Requests perform writes through the modules themselves and not the added service.
Second option:
Create a service that owns a copy of module1, module2 and module3. (composition)
The service delegates actions to the modules based on what is required from it.
The service keeps the list of files accessed since the requests were made through it.
The request stops using the modules directly - uses the service instead.
Both these approaches have advantages and disadvantages. A more complicated solution might be required (those two are in practice pretty simple to do) where the services are abstracted further but I think this is a good start.
One simple way is storing data on the request object.
Here is an example (using Express):
app.get('/hello.txt', function(req, res){
req.transaction = req.transaction || [];
if (req.transaction.length) {
// something else has already written to this array
}
});
However, I don't really see how you can need this. When you call moduleA or moduleB, you just have to pass an object as argument, and it solves your issue. Maybe you're looking for dependency injection?
using koa ctx.state doc for this scenario, in express I believe this Plugin should serve your needs.
in order to keep some data that will be resused by another request on the save server app, I propose to use session in expresse and avoid any global state or any props drilling from one request to another.
In order to manage session state in express you could use :
session-file-store save the session in a file
express-mongodb-session : save the session in mongoDb
mssql-session-store -> for a relation db
Of course there is another technique ti manage session in NodeJs.