netbpm.xml

工作流

            </summary>
            <seealso href="http://www.netbpm.org/docs/npdl.html">
            </seealso>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.Impl.Action.EmailAction">
            <summary> sends an email.</summary>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.IActionHandler">
            <summary> is the delegation-interface for the execution of process-initiated actions.
            <p>Interactions are used to communicate with the existing infrastructure in an organisation.
            The {@link InteractionContext} allows the Interaction-developer to access all information
            about the process instance.
            </p>
            
            NetBpm provides a lot of ready-to-use, configurable interactions such as...
            <ul>
            <li>DB-query of update</li>
            <li>Sending an email</li>
            <li>Calling one or more web-services</li>
            <li>Interacting with an ERP-package over JCA</li>
            <li>Sending an EDI-message</li>
            <li>Putting a message on an enterprise service bus</li>
            <li>...</li>
            </ul>
            </summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IActionHandler.Run(NetBpm.Workflow.Delegation.IActionContext)">
            <summary> implements the process-initiated action.</summary>
            <param name="actionContext">is the object that allows the Interaction-implementator to communicate with the NetBpm process engine.
            </param>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.Impl.Assignment.AssignmentExpressionResolver">
            <summary> allows to specify the next-actor in a process definition as an expression using the following syntax.
            <p>The general syntax is firstArgument->nextArgument->nextArgument->...->nextArgument
            </p> 
            <p>For the firstArgument, following constructions are valid :
            <ul>
            <li><b>previousActor</b> : </li>
            <li><b>actor( &lt;actorName&gt; )</b> : </li>
            <li><b>user( &lt;userName&gt; )</b> : </li>
            <li><b>group( &lt;groupName&gt; )</b> : </li>
            </ul>
            </p> 
            <p>For the nextArgument's, following constructions are valid :
            <ul>
            <li><b>[User]->group( &lt;membership-type&gt; )</b> results in a Group</li>
            <li><b>[Group]->role( &lt;role&gt; )</b> results in a User</li>
            <li><b>[Group]->parentGroup</b> results in a Group</li>
            </ul>
            </p> 
            </summary>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.IAssignmentHandler">
            <summary> is the delegation interface for selecting the {@link NetBpm.Workflow.Organisation.IUser} or 
            {@link NetBpm.Workflow.Organisation.IGroup} that will be assigned as actor for an acitivity.
            
            <p>After the assignment of an actor to an activity, the actor is the only user that is 
            able to act upon the activity. An actor of an activity can do one of the following actions : 
            <ul>
            <li>perform the activity</li>
            <li>delegate the activity to another user</li>
            <li>cancel the flow</li>
            <li>cancel the process instance</li>
            </ul> 
            </p>
            
            <p>If an activity is assigned to a {@link NetBpm.Workflow.Organisation.IGroup}, the
            members of that group are able to pull the activity to their tasklist.  Currently group-members
            can just perform tasks of their group without pulling the task explicitly to their
            personal tasklist.  This could result in an exception being thrown from the performActivity
            method if 2 users try to perform the same activity at the same time.  It would be a better API
            design to have members pull tasks to their personal tasklist before allowing them to 
            perform the tasks.  That way there can be no conflict so no exception has to be thrown.  But
            this pulling mechanism still has to be implemented.
            </p>
            
            <p>If the returned id is the id of a {@link NetBpm.Workflow.Organisation.IUser}, that 
            {@link NetBpm.Workflow.Organisation.IUser} will get this activity in his/her tasklist.
            The {@link NetBpm.Workflow.Organisation.IUser} is then assigned to the activity as described above.
            </p>
            
            <p>If the returned id is the id of {@link NetBpm.Workflow.Organisation.IGroup}, the 
            {@link NetBpm.Workflow.Organisation.IGroup} will be assigned to the activity.
            Nobody is able to perform an {@link NetBpm.Workflow.Definition.IActivityState} that is 
            assigned to a {@link NetBpm.Workflow.Organisation.IGroup} directly.
            First, the wanne-be-actor has to pull the {@link NetBpm.Workflow.Definition.IActivityState}
            from his {@link NetBpm.Workflow.Organisation.IGroup} in his own
            tasklist.  People are only able to pull activities from their own 
            {@link NetBpm.Workflow.Organisation.IGroup}(s).
            After someone pulls an {@link NetBpm.Workflow.Definition.IActivityState}, the 
            {@link NetBpm.Workflow.Definition.IActivityState} is assigned to the 
            {@link NetBpm.Workflow.Organisation.IUser} as described above.
            </p>
            </summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IAssignmentHandler.SelectActor(NetBpm.Workflow.Delegation.IAssignmentContext)">
            <summary> performs the assignment of a {@link NetBpm.Workflow.Organisation.IUser} or a 
            {@link NetBpm.Workflow.Organisation.IGroup} to an {@link NetBpm.Workflow.Definition.IActivityState}
            in a {@link NetBpm.Workflow.Execution.IFlow}.
            </summary>
            <param name="assignerContext">is the object that allows the Assigner-implementator to communicate with the NetBpm process engine.
            </param>
            <returns> the id of the actor (= user or group) that must be assigned to the {@link NetBpm.Workflow.Definition.IActivityState}
            </returns>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.IDecisionHandler">
            <summary> if more then one {@link NetBpm.Workflow.Definition.ITransition} leaves an 
            {@link NetBpm.Workflow.Definition.IActivityState}, a Decision chooses the 
            {@link NetBpm.Workflow.Definition.ITransition} 
            that has to be activated when the {@link NetBpm.Workflow.Definition.IActivityState}
            is performed.
            See also <a href="http://www.netbpm.org/docs/architecture.html#The+delegation+principle">The delegation principle</a>.
            </summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IDecisionHandler.Decide(NetBpm.Workflow.Delegation.IDecisionContext)">
            <summary> decides which of the {@link NetBpm.Workflow.Definition.ITransition}'s, after 
            performing an {@link NetBpm.Workflow.Definition.IActivityState}, has to be activated. 
            </summary>
            <param name="decisionContext">is the object that allows the Decision-implementator to communicate with the NetBpm process engine.
            </param>
            <returns> the name of the choosen {@link NetBpm.Workflow.Definition.ITransition}.
            </returns>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.IForkHandler">
            <summary> specifies the behaviour of a {@link NetBpm.Workflow.Definition.IFork}.</summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IForkHandler.Fork(NetBpm.Workflow.Delegation.IForkContext)">
            <summary> calculates the names of the {@link NetBpm.Workflow.Definition.ITransition}s to be activated
            concurrently. The same name can be added multiple times to start multiple instances of the 
            same flow.  All of the forked {@link NetBpm.Workflow.Execution.IFlow}s will be synchronized 
            in the same {@link NetBpm.Workflow.Definition.IJoin}.  
            </summary>
            <param name="forkContext">is the object that allows the Forker-implementator to communicate with the netBpm process engine.
            </param>
            <returns> a Collection of {@link NetBpm.Workflow.Definition.ITransition}s for which a concurrent {@link NetBpm.Workflow.Execution.IFlow} has to be created.
            </returns>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.IHtmlFormatter">
            <summary> is an interface used for the automatic generation of activity-forms in the web-interface.
            <b>IMPORTANT NOTE</b> : In the web-interface, the class-name is used as a key for finding 
            the internationalized name of this HtmlFormatter.
            It is used when a ParseException is thrown in {@link #parseHttpParameter} to inform
            the user what kind of data whas excpected.  The error-msg is constructed like
            this : "Wrong input for field [field-name].  [received-value] could not be
            parsed as [translated text for html-formatter]"
            </summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IHtmlFormatter.ObjectToHtml(System.Object,System.String,System.Web.HttpRequest)">
            <summary> generates a HTML-fragment that is used to produce the automatically generated 
            web-form that allows a user to perform an activity.
            </summary>
            <param name="valueObject">is the current {@link NetBpm.Workflow.Execution.IAttributeInstance} 
            value for the attribute for which html has to be generated.
            </param>
            <param name="parameterName">is the name of the http-parameter on which the NetBpm 
            web-application will expect input for this attribute.  If input is 
            present for that parameter-name, it is parsed using the parseHttpParameter-method
            </param>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IHtmlFormatter.ParseHttpParameter(System.String,System.Web.HttpRequest)">
            <summary> parses the text that is returned by the web-client to an java-object before it is 
            stored in an {@link NetBpm.Workflow.Execution.IAttributeInstance}.
            </summary>
            <param name="text">is the String that is passed from the web-client to the server
            for html-input-control that was generated with the objectToHtml-method.
            </param>
            <returns> the parsed java-object that will be stored in an 
            {@link NetBpm.Workflow.Execution.IAttributeInstance}. 
            @throws ParseException if the text is not what this HtmlFormatter expects.  A 
            ParseException will cause the web-application to go back to the form with an 
            error message as explained above. 
            </returns>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.IJoinHandler">
            <summary> allows to specify all kinds of {@link NetBpm.Workflow.Definition.IJoin}-behaviour, 
            including run-time process-specific behaviour.
            </summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.IJoinHandler.Join(NetBpm.Workflow.Delegation.IJoinContext)">
            <summary> for every {@link NetBpm.Workflow.Execution.IFlow} that arrives in a 
            {@link NetBpm.Workflow.Definition.IJoin} a Joiner calculates if the 
            parent-{@link NetBpm.Workflow.Execution.IFlow} should be reactivated.
            The parent-{@link NetBpm.Workflow.Execution.IFlow} can only be reactivated
            once.  The Joiner will not be called for all {@link NetBpm.Workflow.Execution.IFlow}s 
            that arrive in a {@link NetBpm.Workflow.Definition.IJoin} after the 
            parent-{@link NetBpm.Workflow.Execution.IFlow} is reactivated.
            If no Joiner is specified for a Join in the processdefinition.xml, 
            the parent-flow will be reactevated when the last active concurrent flow 
            arrives in the Join.
            </summary>
            <param name="joinContext">is the object that allows the Joiner-implementator to communicate with the NetBpm process engine.
            </param>
            <returns> true if the parent-flow should be reactivated or false otherwise.
            </returns>
        </member>
        <member name="T:NetBpm.Workflow.Delegation.ISerializer">
            <summary> performs (de)serialisation of {@link NetBpm.Workflow.Execution.IAttributeInstance}-values (which are ordinary java-objects), for storage in the database.
            It is even possible to use a process specific java-type as {@link NetBpm.Workflow.Execution.IAttributeInstance}-value.
            </summary>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.ISerializer.Serialize(System.Object)">
            <summary> serializes the value of an {@link NetBpm.Workflow.Execution.IAttributeInstance}
            to store it in the database.
            </summary>
            <param name="valueObject">is the java-object that represents the value for the {@link NetBpm.Workflow.Execution.IAttributeInstance}
            @throws IllegalArgumentException if object is not serializable by this serializer
            </param>
        </member>
        <member name="M:NetBpm.Workflow.Delegation.ISerializer.Deserialize(System.String)">