A UI mockup for the executable processes is attached. The main content of this artifact is a process archive. A description and a set of properties can be associated with it. Deployment URL, Webapp URL, developers, IT support staff, etc are captured as properties. Description can have links to related artifacts (e.g. textual process explaining the process steps). Buttons for runtime analysis and reporting issues are also added, but will be implemented later. Runtime analysis is focused on capturing events of executed processes and generating graphs, reports, etc.
We can add more features into this in future versions such as defining and enforcing rules based on events. Regards, Chathura On Mon, Dec 15, 2014 at 9:31 AM, Chathura Ekanayake <[email protected]> wrote: > > Hi Frank, > > Sorry for the delay in replying. Somehow missed this. > > > >> ​what is the semantics of the deployment URL (second bullet): is this >> the endpoint where a BPEL archive can be deployed? Or is this the URL of an >> archive that contains all the artifacts to create a BPEL engine where I can >> deploy and execute the BPEL file? I suspect the first alternative is what >> you mean - just double-check. >> >> > Yes, this is the first alternative. i.e. URL of a running BPS > engine/cluster where a BPEL or BPMN archive can be deployed. > > >> I don't understand your third bullet: when you deploy a BPEL archive you >> (nearly always) deploy all roles of all partner links. After that an >> instance of the process model can be instantiated by any external source by >> sending messages to the ports that correspond to initiating activities of >> the process model. The same is true in case a BPEL file uses the >> BPEL4People extension, i.e. in case some activities are implemented by >> human tasks. >> >> Continuing on the "Webapp URL" (it must be something implementation >> specific that we have done at WSO2): A process model may be initiated by >> activities that have not user interaction at all (i.e. that is no >> peopleActivity activity kicking-off a new instance of the process model). >> What is the Webapp URL all about in this case? >> > > A webapp URL is mostly useful when a process has human interactions (i.e. > human tasks). In that case usually a web application is developed to view > task lists and work on tasks. Webapp URL is the URL of such web > application. If a new webapp is not available, it can point to the URL of > the builtin human task webapp (which is under development). If a process > does not have any human tasks, such web app is not much useful except for > providing input values defined in process's WSDL. I think still it is > better to have a (built-in) webapp just for starting a non-human centric > process than using something like tryit tool in process center (as this is > targeted more towards business users). > > >> Pushing the "deploy" button is done by non-business-oriented users >> because it will require quite some technical information, right? I.e. do we >> support in the Process Store corresponding role models to avoid >> "frustration" by business users when pushing the "deploy" button? >> > > Yes, we are planning to support a role based authorization model, which > can be used to control such things. > > Regards, > Chathura > >> >>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
