JIRA for tracking this feature: https://wso2.org/jira/browse/PC-5
Regards, Chathura On Mon, Dec 15, 2014 at 1:59 PM, Chathura Ekanayake <[email protected]> wrote: > > 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
