Current progress
Hello everyone,
I’ve just wanted to quick update everyone on what I’m working on and things that should be done in the near future.
- So right now my main focus is getting data objects from server to web app and vice versa. Unfortunately I struggle here a bit, because for now I see it as we’ve mentioned it before, to export that data object as JSON, and then recompile it on the web app. Norbert mentioned something, that he really doesn’t like that, and I’m curious because if there’s another way I would love to try it, just don’t know where to start.
So basically this is what we have:
Task, which has a dataObject bound to it. When the process is started that task is picked up by the engine, and data object bound to the task is served as JSON.
WebApp, fetches that json and uses it to recompile it again as an object on the web app. After recompiling form is rendered, where user can submit it’s data which is again transformed into JSON and sent to server.
This is the main focus for now.
The other one is decoupling model and execution, because I want to make possible for the engine to execute multiple instances of the same process (it only works on 1 for now).
Cheers,
Sebastijan
--
Pozdrav / Best regards,
Sebastijan Kaplar
Fakultet tehničkih nauka
Univerzitet u Novom Sadu
Hi,
I‘m sorry but I couldn‘t do anything. I got sick two weeks before and is still ongoing so I‘m not sure I can do anything this year.
Am 11.12.2019 um 13:57 schrieb Sebastijan Kaplar kaplar@uns.ac.rs:
Hello everyone,
I’ve just wanted to quick update everyone on what I’m working on and things that should be done in the near future.
- So right now my main focus is getting data objects from server to web app and vice versa. Unfortunately I struggle here a bit, because for now I see it as we’ve mentioned it before, to export that data object as JSON, and then recompile it on the web app. Norbert mentioned something, that he really doesn’t like that, and I’m curious because if there’s another way I would love to try it, just don’t know where to start.
The current flow with web ui is in a way that the business object (the dataObject) is a known class in the workflow engine runtime. For this object a magritte description is generated and exported via JSON. The web ui runtime takes the description and compiles a class for it. I think this step is unnecessary and brittle. The form is geberated from the description. Having the description for the object a dictionary should be sufficient to hold the values for that object. The sole purpose of holding the values is to serialize them and send back in JSON serialized format which is straightforward with a dictionary. I cannot tell it from my head if this is already possible or we have to add something. I can see if I can provide something soon.
So basically this is what we have:
Task, which has a dataObject bound to it. When the process is started that task is picked up by the engine, and data object bound to the task is served as JSON.
WebApp, fetches that json and uses it to recompile it again as an object on the web app. After recompiling form is rendered, where user can submit it’s data which is again transformed into JSON and sent to server.
This is the main focus for now.
The other one is decoupling model and execution, because I want to make possible for the engine to execute multiple instances of the same process (it only works on 1 for now).
That is a good point. I noticed that the engine is the singular point of organized flow. Changing that feels like an improvement.
Norbert
Cheers,
Sebastijan
--
Pozdrav / Best regards,
Sebastijan Kaplar
Fakultet tehničkih nauka
Univerzitet u Novom Sadu
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org
On Dec 12, 2019, at 11:22, Norbert Hartl norbert@hartl.name wrote:
Hi,
I‘m sorry but I couldn‘t do anything. I got sick two weeks before and is still ongoing so I‘m not sure I can do anything this year.
Oh, get well soon! It’s not a rush I’m working on it.
Am 11.12.2019 um 13:57 schrieb Sebastijan Kaplar kaplar@uns.ac.rs:
Hello everyone,
I’ve just wanted to quick update everyone on what I’m working on and things that should be done in the near future.
- So right now my main focus is getting data objects from server to web app and vice versa. Unfortunately I struggle here a bit, because for now I see it as we’ve mentioned it before, to export that data object as JSON, and then recompile it on the web app. Norbert mentioned something, that he really doesn’t like that, and I’m curious because if there’s another way I would love to try it, just don’t know where to start.
The current flow with web ui is in a way that the business object (the dataObject) is a known class in the workflow engine runtime. For this object a magritte description is generated and exported via JSON. The web ui runtime takes the description and compiles a class for it. I think this step is unnecessary and brittle. The form is geberated from the description. Having the description for the object a dictionary should be sufficient to hold the values for that object. The sole purpose of holding the values is to serialize them and send back in JSON serialized format which is straightforward with a dictionary. I cannot tell it from my head if this is already possible or we have to add something. I can see if I can provide something soon.
So this is changed and a different a bit, let me explain:
DataObject is indeed a known class in the workflow engine runtime. Now for this object, we use a couple of wrapper classes NewWaveDOClassDescription, NewWaveDOPropertyDescription, NewWaveDOJSONExporter. This classes are used to create JSON from the data object, to look like something like this:
{
"className" : "Adresa",
"properties" : [
{
"varName" : "ulica",
"varType" : "ByteString",
"varValue" : "Test Place"
},
{
"varName" : "broj",
"varType" : "ByteString",
"varValue" : "Test Street"
},
{
"varName" : "id",
"varType" : "ByteString",
"varValue" : "1"
}
]
}
Now this is the JSON that is picked up by the web app. When the web app, fetches that json, it uses NewWaveDOJSONImporter, NewWaveDOClassDescription, NewWaveDOPropertyDescription in order to recreate the sent object on the Web application, and this is important NewWaveMagritteContainerCreator, which is used only on the web app to generate magritte descriptions for that object. So basically engine runtime, doesn’t need to know about the magritte descriptions.
Now, as we test this we have NewWave Engine, and WebApp in the the same Pharo image, and the idea somewhere is that the web app could be standalone (doesn’t need the engine to run) in separate Pharo image. Which is why we are exporting the data object as json, and then recompiling it on the web app. Hope this makes sense.
But the thing you mentioned, which is something I’m still thinking how:
Having the description for the object a dictionary should be sufficient to hold the values for that object. The sole purpose of holding the values is to serialize them and send back in JSON serialized format which is straightforward with a dictionary. I cannot tell it from my head if this is already possible or we have to add something. I can see if I can provide something soon.
Is what to send to from the web app to the NewWaveEngine, updated previously pasted JSON, or something similiar, because dataObject already exists on the engine, and recompiling it again seems a bit too much, probably just updating the fields or something similar.
Sebastijan
So basically this is what we have:
Task, which has a dataObject bound to it. When the process is started that task is picked up by the engine, and data object bound to the task is served as JSON.
WebApp, fetches that json and uses it to recompile it again as an object on the web app. After recompiling form is rendered, where user can submit it’s data which is again transformed into JSON and sent to server.
This is the main focus for now.
The other one is decoupling model and execution, because I want to make possible for the engine to execute multiple instances of the same process (it only works on 1 for now).
That is a good point. I noticed that the engine is the singular point of organized flow. Changing that feels like an improvement.
Norbert
Cheers,
Sebastijan
--
Pozdrav / Best regards,
Sebastijan Kaplar
Fakultet tehničkih nauka
Univerzitet u Novom Sadu
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org
Hi, hope you are better.
Apart from things Sebastijan has mentioned, there are few other development tracks students are currently pursuing:
- enabling the workflow engine to do the proper assignment of tasks (allocating task to specific users or users in specific roles)
- model parsing from external input format (XMI, BPMN)
- the persistence of the process instances (running processes)
- making engine capable of running multiple instances of same or different process models (Sebastijan also mentioned it)
I like your simplified idea to use dictionaries to enable form rendering - current approach was based on assumption that it would be nice to have complete object on the client side (especially if some sort of temporary persisting is required on the client side as Cedrick has hinted would be very nice feature for users that are frequently offline).
Best regards,
Miroslav
On 12 Dec 2019, at 11:22, Norbert Hartl norbert@hartl.name wrote:
Hi,
I‘m sorry but I couldn‘t do anything. I got sick two weeks before and is still ongoing so I‘m not sure I can do anything this year.
Am 11.12.2019 um 13:57 schrieb Sebastijan Kaplar <kaplar@uns.ac.rs mailto:kaplar@uns.ac.rs>:
Hello everyone,
I’ve just wanted to quick update everyone on what I’m working on and things that should be done in the near future.
- So right now my main focus is getting data objects from server to web app and vice versa. Unfortunately I struggle here a bit, because for now I see it as we’ve mentioned it before, to export that data object as JSON, and then recompile it on the web app. Norbert mentioned something, that he really doesn’t like that, and I’m curious because if there’s another way I would love to try it, just don’t know where to start.
The current flow with web ui is in a way that the business object (the dataObject) is a known class in the workflow engine runtime. For this object a magritte description is generated and exported via JSON. The web ui runtime takes the description and compiles a class for it. I think this step is unnecessary and brittle. The form is geberated from the description. Having the description for the object a dictionary should be sufficient to hold the values for that object. The sole purpose of holding the values is to serialize them and send back in JSON serialized format which is straightforward with a dictionary. I cannot tell it from my head if this is already possible or we have to add something. I can see if I can provide something soon.
So basically this is what we have:
Task, which has a dataObject bound to it. When the process is started that task is picked up by the engine, and data object bound to the task is served as JSON.
WebApp, fetches that json and uses it to recompile it again as an object on the web app. After recompiling form is rendered, where user can submit it’s data which is again transformed into JSON and sent to server.
This is the main focus for now.
The other one is decoupling model and execution, because I want to make possible for the engine to execute multiple instances of the same process (it only works on 1 for now).
That is a good point. I noticed that the engine is the singular point of organized flow. Changing that feels like an improvement.
Norbert
Cheers,
Sebastijan
--
Pozdrav / Best regards,
Sebastijan Kaplar
Fakultet tehničkih nauka
Univerzitet u Novom Sadu
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org
Yes, thanks.
Apart from things Sebastijan has mentioned, there are few other development tracks students are currently pursuing:
- enabling the workflow engine to do the proper assignment of tasks (allocating task to specific users or users in specific roles)
- model parsing from external input format (XMI, BPMN)
- the persistence of the process instances (running processes)
- making engine capable of running multiple instances of same or different process models (Sebastijan also mentioned it)
is the progress on this somehow visible? Sounds all pretty interesting.
I like your simplified idea to use dictionaries to enable form rendering - current approach was based on assumption that it would be nice to have complete object on the client side (especially if some sort of temporary persisting is required on the client side as Cedrick has hinted would be very nice feature for users that are frequently offline).
I think there can be benefits to have the complete object on the client side. But you only copy the object shape and instance variables, no behavior. So the niceness of this object is not so huge after all. Depending on the use case creating classes can even prevent that because they are global state and two instances with the same name will conflict there. I think a dictionary is pretty good to do persistence. Or a derived class containig also the name of class.
Norbert
Best regards,
Miroslav
On 12 Dec 2019, at 11:22, Norbert Hartl <norbert@hartl.name mailto:norbert@hartl.name> wrote:
Hi,
I‘m sorry but I couldn‘t do anything. I got sick two weeks before and is still ongoing so I‘m not sure I can do anything this year.
Am 11.12.2019 um 13:57 schrieb Sebastijan Kaplar <kaplar@uns.ac.rs mailto:kaplar@uns.ac.rs>:
Hello everyone,
I’ve just wanted to quick update everyone on what I’m working on and things that should be done in the near future.
- So right now my main focus is getting data objects from server to web app and vice versa. Unfortunately I struggle here a bit, because for now I see it as we’ve mentioned it before, to export that data object as JSON, and then recompile it on the web app. Norbert mentioned something, that he really doesn’t like that, and I’m curious because if there’s another way I would love to try it, just don’t know where to start.
The current flow with web ui is in a way that the business object (the dataObject) is a known class in the workflow engine runtime. For this object a magritte description is generated and exported via JSON. The web ui runtime takes the description and compiles a class for it. I think this step is unnecessary and brittle. The form is geberated from the description. Having the description for the object a dictionary should be sufficient to hold the values for that object. The sole purpose of holding the values is to serialize them and send back in JSON serialized format which is straightforward with a dictionary. I cannot tell it from my head if this is already possible or we have to add something. I can see if I can provide something soon.
So basically this is what we have:
Task, which has a dataObject bound to it. When the process is started that task is picked up by the engine, and data object bound to the task is served as JSON.
WebApp, fetches that json and uses it to recompile it again as an object on the web app. After recompiling form is rendered, where user can submit it’s data which is again transformed into JSON and sent to server.
This is the main focus for now.
The other one is decoupling model and execution, because I want to make possible for the engine to execute multiple instances of the same process (it only works on 1 for now).
That is a good point. I noticed that the engine is the singular point of organized flow. Changing that feels like an improvement.
Norbert
Cheers,
Sebastijan
--
Pozdrav / Best regards,
Sebastijan Kaplar
Fakultet tehničkih nauka
Univerzitet u Novom Sadu
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org mailto:Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org
Hi Norbert,
comments inline
On 5 Feb 2020, at 14:21, Norbert Hartl norbert@hartl.name wrote:
Am 19.12.2019 um 17:28 schrieb Miroslav Zaric <miroslavzaric@uns.ac.rs mailto:miroslavzaric@uns.ac.rs>:
Hi, hope you are better.
Yes, thanks.
Apart from things Sebastijan has mentioned, there are few other development tracks students are currently pursuing:
- enabling the workflow engine to do the proper assignment of tasks (allocating task to specific users or users in specific roles)
- model parsing from external input format (XMI, BPMN)
- the persistence of the process instances (running processes)
- making engine capable of running multiple instances of same or different process models (Sebastijan also mentioned it)
is the progress on this somehow visible? Sounds all pretty interesting.
Currently they are working on their local machines and consulting with Sebastijan. When they align their development with what Sebastijan expect they will create pull request and Sebastijan will merge the code to its main branch.
Sebastijan will determine the moment to do this.
I like your simplified idea to use dictionaries to enable form rendering - current approach was based on assumption that it would be nice to have complete object on the client side (especially if some sort of temporary persisting is required on the client side as Cedrick has hinted would be very nice feature for users that are frequently offline).
I think there can be benefits to have the complete object on the client side. But you only copy the object shape and instance variables, no behavior. So the niceness of this object is not so huge after all. Depending on the use case creating classes can even prevent that because they are global state and two instances with the same name will conflict there. I think a dictionary is pretty good to do persistence. Or a derived class containig also the name of class.
Yes I agree that dictionary is fully valid approach, especially since it will straightforwardly map to JSON notation when we are ready to support any kind of client.
Best regards,
Miroslav
Norbert
Best regards,
Miroslav
On 12 Dec 2019, at 11:22, Norbert Hartl <norbert@hartl.name mailto:norbert@hartl.name> wrote:
Hi,
I‘m sorry but I couldn‘t do anything. I got sick two weeks before and is still ongoing so I‘m not sure I can do anything this year.
Am 11.12.2019 um 13:57 schrieb Sebastijan Kaplar <kaplar@uns.ac.rs mailto:kaplar@uns.ac.rs>:
Hello everyone,
I’ve just wanted to quick update everyone on what I’m working on and things that should be done in the near future.
- So right now my main focus is getting data objects from server to web app and vice versa. Unfortunately I struggle here a bit, because for now I see it as we’ve mentioned it before, to export that data object as JSON, and then recompile it on the web app. Norbert mentioned something, that he really doesn’t like that, and I’m curious because if there’s another way I would love to try it, just don’t know where to start.
The current flow with web ui is in a way that the business object (the dataObject) is a known class in the workflow engine runtime. For this object a magritte description is generated and exported via JSON. The web ui runtime takes the description and compiles a class for it. I think this step is unnecessary and brittle. The form is geberated from the description. Having the description for the object a dictionary should be sufficient to hold the values for that object. The sole purpose of holding the values is to serialize them and send back in JSON serialized format which is straightforward with a dictionary. I cannot tell it from my head if this is already possible or we have to add something. I can see if I can provide something soon.
So basically this is what we have:
Task, which has a dataObject bound to it. When the process is started that task is picked up by the engine, and data object bound to the task is served as JSON.
WebApp, fetches that json and uses it to recompile it again as an object on the web app. After recompiling form is rendered, where user can submit it’s data which is again transformed into JSON and sent to server.
This is the main focus for now.
The other one is decoupling model and execution, because I want to make possible for the engine to execute multiple instances of the same process (it only works on 1 for now).
That is a good point. I noticed that the engine is the singular point of organized flow. Changing that feels like an improvement.
Norbert
Cheers,
Sebastijan
--
Pozdrav / Best regards,
Sebastijan Kaplar
Fakultet tehničkih nauka
Univerzitet u Novom Sadu
--
Workflow-engine mailing list
Workflow-engine@lists.pharo.org mailto:Workflow-engine@lists.pharo.org
http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org http://lists.pharo.org/mailman/listinfo/workflow-engine_lists.pharo.org