We want to use a process to fill the dynamic content of our template so that we don’t have to encode all parameters into the calling URL.

The process definition for this tasks looks like this:

<?xml version="1.0" encoding="UTF-8" ?>
<process>
   <description> 
      <output>
         <state>ok</state> 
         <result name="welcomePage" 
                 description="composedPage" 
                 content-type="text/html" 
                 presentable="true" /> 
      </output>
   </description>

   <step id="compose" processor="hello"> 
      <load parameter="username"> 
          <string>Tony</string> 
      </load>
      <load parameter="style"> 
          <string>color:red;font:italic;</string> (11)
      </load>
      <save result="output" (12)
            store=”output” (13)
            key="welcomePage" (14)
            presentable="true"/> (15)
      <route state="ok" return="ok" /> (16)
   </step>
</process>

	The description element contains the contract of this process. The contract describes the required parameters, the provided results and the possible return states as described in the chapter Projector basics
	The only state that this process can return is the state with the identifier OK
	Only one result is provided. The result is accessible via its name welcomePage
	The description attribute of the result contains a key to the localized description. This detailed description must be added to any message file that the Message Manager is aware of
	The content type of this result is of type text/html as the generated page will be a valid HTML document.
	We declare this result presentable as it can be displayed to the user
	Our process consists of a single step with the id compose. When this step gets launched the processor with the given URL hello will be invoked. This is exactly the processor that we have registered in our previous example.
	Before the processor gets launched, values can be assigned to the required parameters. The parameter attribute identifies a parameter by its name. In this example we assign a value to the parameters username and style.
	We load the parameters with suitable string values.
	We want to save the result with the key output. This is the result that the template processor registered under the URL hello provides. If you don’t remember this, take a look back at the chapter Projector basics. Note If the processor that is associated with the step provides more than one result, you should remember that every result that is not saved will be lost.
(11)	We save the result with the key output to the output store of this process by using the defined key welcomePage that we have defined in the contract of this process. So this result will be accessible to the caller of our process.
(14)	The result that we bind to the key welcomePage can be displayed to the user so we define it as a presentable result.
(16)	We route the state ok of the template processor to the return state ok of our process. Return states are identified by a string. The string ok is the convention for indicating that everything went fine.

Create a file with this process definition in the content/site folder of our project and call it welcome.xml. In order to test our process we have to add it to the processor registry:

<?xml version="1.0" encoding="UTF-8" ?> 
<processors>
   <processor uri="hello" 
              config-uri="templates/helloWorld.tmpl" 
              class="org.apache.slide.projector.processor.TemplateRenderer" />
   <processor uri="welcome.html" 
              config-uri="site/welcome.xml"
              class="org.apache.slide.projector.processor.process.Process" /> 
</processors>

We add a new processor to our registry with the implementing class Process. We tell Projector that this process will be accessible via the URL welcome.html and the process definition can be found at the relative URL site/welcome.xml.

As you see in this first workflow lesson, the implementing class Process that deals with workflows is just another configurable processor. In opposite to the first configurable processor that we have known, the template processor, the configuration file contains no template but the process definition. We register this processor and the associated configuration file just in the same way as we have already done it using the template processor.

The best thing of it all: We can use our newly defined process as a processor in other process definitions! By this way we can easily create nested workflows. We will heavily use this great feature in our upcoming examples.

But before we continue we should test our work by uploading the changes and calling the defined process. This can be done by invoking the associated URL as we already have learned:

http://localhost:8080/projector/welcome.html

The result page looks well known:

Figure 7.1. The result of the process