Joshua Yip writes:
> hey nick....my workflow engine seems to devour the same xml too. What
> standards is yours based on ?
Off hand I don't think its based on any one standard, though I don't
know for sure since I wasn't around when it was started.
The entities used in the XML seem pretty standard though
(roles, activities).
>And how is it selling?
Its not really the workflow that we sell. We're a software/services
company and the workflow aspect is used by companies to define their
human resource business processes (i.e. vacation requests,
performance reviews, employee terminations). So we sell application
modules that make use of our underlying workflow engine.
It also takes months to get our product up and running because
it must tie into the company's employee database so its a big
investment on the customer's part and a hard sell. That's common
to this niche market. I'll try to answer your your question by
saying we have customers but need more...
--
Nick
> Jonathan, here is some of your meat !!
> Staff DocType
>
> <STAFF ID="LOANMANAGER">
> <Name>Revu Masur</Name>
> <UserID>MA001</UserID>
> <Password>********</Password>
> <Contact>
> <Phone>03-782 5834</Phone>
> <Phone>03-782 5935</Phone>
> <E-Mail>[EMAIL PROTECTED]</E-Mail>
> <E-Mail>[EMAIL PROTECTED]</E-Mail>
> </Contact>
> <OrganisationUnits>
> <OrganisationUnit ID="BranchA"/>
> </OrganisationUnits>
> <Roles>
> <Role ID="BM"/>
> </Roles>
> <Level Rank="1"/>
> </STAFF>
>
> Roles Doc Type
> <Roles ID="HLBB"
> NAME="Hong Leong Bank Berhad">
> <Role ID="AM"
> NAME="Assistant Manager">
> <Members StaffID="AMAA001"/>
> <Members StaffID="AMAB002"/>
> </Role>
> <Role ID="BM"
> NAME="Branch Manager">
> <Members StaffID="MA001"/>
> <Members StaffID="MB002"/>
> </Role>
> <Role ID="LO"
> NAME="Loan Officer">
> <Members StaffID="LO001"/>
> <Members StaffID="LO002"/>
> <Members StaffID="LO003"/>
> <Members StaffID="LO004"/>
> <Members StaffID="LO005"/>
> <Members StaffID="LO006"/>
> <Members StaffID="LO007"/>
> </Role>
> <Role ID="RM"
> NAME="Regional Manager">
> <Members StaffID="RM001"/>
> <Members StaffID="RM002"/>
> <Members StaffID="RM003"/>
> </Role>
> <Role ID="GM"
> NAME="General Manager">
> <Members StaffID="GM001"/>
> </Role>
> </Roles>
>
> <OrganisationUnit ID="XXXX">
> <Name>
> Acme Comp
> </Name>
> <Manager ID="A002"/>
> </OrganisationUnit>
>
>
> And a few more doctype
>
>
>
>
>
>
>
> XML is the future!
>
> Joshua Yip
> Software Developer
> IB-DOCS.COM
> Intelligent Business Document dot Com
> Office email: [EMAIL PROTECTED]
> Personal Email:[EMAIL PROTECTED]
> YahooID: joshuayip
> ICQ:8657630
>
> ----- Original Message -----
> From: "Nick Afshartous" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 06, 2001 9:15 PM
> Subject: Re: Work flow RFC
>
>
>
> My company developed an XML-based workflow engine for our product.
> Its not graphical but users can fill out forms in order to
> create the XML process definition. The XML process definition
> contains the workflow roles, activities, and activity transitions.
> --
>
> Nick
>
>
>
> Jonathan Asbell writes:
> > Is there anyone on the list that actually HAS experience developing with
> > workflow engines?
> >
> > ----- Original Message -----
> > From: "Rey Francois" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, June 06, 2001 4:40 AM
> > Subject: RE: Work flow RFC
> >
> >
> > > Another possibility is to develop extensions for the TogetherJ CASE
> tool.
> > It
> > > is entirely written in Java, therefore can run on most platform, and
> from
> > my
> > > understanding it is possible to define new diagram types and patterns.
> > >
> > > This may not directly relate to workflow, but we have in our team
> created
> > > the concept of a request servicing diagram which is a class diagram
> > > representing the objects involved in servicing a request. Particularly
> on
> > > this diagram we display the request object and the action it is mapped
> to.
> > > Although we have not done it yet, it is quite possible to develop a
> > pattern
> > > that generates the corresponding action mapping entry in the
> > > struts-config.xml, and vice-versa.
> > >
> > > François Rey
> > > Financial WebSuite
> > > Capco
> > > http://www.capco.com/
> > >
> > >
> > > -----Original Message-----
> > > From: Craig Tataryn [mailto:[EMAIL PROTECTED]]
> > > Sent: 05 June 2001 20:06
> > > To: Jonathan
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Work flow RFC
> > >
> > >
> > > Is this a workflow editor or just a configuration editor (which would
> be
> > > nice
> > > for struts)?
> > >
> > > craig.
> > >
> > > Jonathan wrote:
> > >
> > > > Again, Ive got to say look at the Barracuda project. They have one
> of
> > > these
> > > > gui configurers. Check it out at
> > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
> > > >
> > > > ----- Original Message -----
> > > > From: "Craig Tataryn" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, June 05, 2001 12:28 PM
> > > > Subject: Work flow RFC
> > > >
> > > > > Hi, I would like your comments for the workflow item on our TODO
> list.
> > > > > Currently this is how I've envisioned the workflow project:
> > > > >
> > > > > 1) A nice GUI type Applet or Application that has visual constructs
> > > > > which can be connected in a Visio type manner to create an Activity
> > > > > diagram or some other type of flow diagram.
> > > > >
> > > > > 2) This diagram will be persisted in an XML file which holds meta
> data
> > > > > for the elements in diagram (position, type of construct
> (controller,
> > > > > flat html page, cgi script, flow arrow, etc..)).
> > > > >
> > > > > 3) The diagram can be exported to a struts config file via XSLT
> (i.e.
> > > > > workflow.xml -> workflow2struts.xsl -> struts-config.xml)
> > > > >
> > > > > 4) A diagram can also be imported from a struts-config.xml file via
> > XSLT
> > > > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml).
> Of
> > > > > course some sort of "pretty layout" code would have to be used to
> > > > > un-jumble the mess of constructs that are sucked out of the
> > > > > struts-config.xml file (i.e. take a guess at proper positioning
> > > > > information).
> > > > >
> > > > > The GUI should employ some sort of extensibility mechanism like BSF
> > > > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean
> > Shell
> > > > > (http://www.beanshell.org/) to allow users to plug-in their own
> > > > > functionality (i.e. validation code) without jeopardizing the core
> > code
> > > > > (what I call the Emeril Lagasse technique -- BAM!).
> > > > >
> > > > > I realize this is a very high level look at the TODO but I think as
> we
> > > > > get more comments we will get more granular and can start dishing
> out
> > > > > segments.
> > > > >
> > > > > Let me know what you think.
> > > > >
> > > > > <tataryn:craig/>
> > > > >
> > >
> > >
> ************************************************************************
> > > The information in this email is confidential and is intended solely
> > > for the addressee(s).
> > > Access to this email by anyone else is unauthorised. If you are not
> > > an intended recipient, you must not read, use or disseminate the
> > > information contained in the email.
> > > Any views expressed in this message are those of the individual
> > > sender, except where the sender specifically states them to be
> > > the views of Capco.
> > >
> > > http://www.capco.com
> > > ***********************************************************************
> > >
> >
>
>
