Author: vanto
Date: Mon Dec 10 18:44:08 2012
New Revision: 1419653

URL: http://svn.apache.org/viewvc?rev=1419653&view=rev
Log:
fix formatting.

Modified:
    ode/site/trunk/content/writing-bpel-test-cases.mdtext

Modified: ode/site/trunk/content/writing-bpel-test-cases.mdtext
URL: 
http://svn.apache.org/viewvc/ode/site/trunk/content/writing-bpel-test-cases.mdtext?rev=1419653&r1=1419652&r2=1419653&view=diff
==============================================================================
--- ode/site/trunk/content/writing-bpel-test-cases.mdtext (original)
+++ ode/site/trunk/content/writing-bpel-test-cases.mdtext Mon Dec 10 18:44:08 
2012
@@ -23,7 +23,7 @@ So to begin with your test process must 
 
 Then for the test framework to know what it should do you will also need to 
write a simple test descriptor. It's a simple properties file saying which 
service is implemented by the process and which messages should be sent to 
start it and make it continue. It should me named test?.properties with the '?' 
being a increasing number. Here is the descriptor for the HelloWorld example, 
in test1.properties:
 
-
+    :::text
     namespace=http://ode/bpel/unit-test.wsdl
     service=HelloService
     operation=hello
@@ -65,6 +65,7 @@ Also if your process needs to receive se
 Finally a response can be marked as being ASYNC in the case no reply is 
expected for a given receive. This only applies to non instantiating receives:
 
 
+    :::text
     response1=ASYNC
 
 
@@ -96,6 +97,7 @@ Practically the probe service takes 2 pa
 Here is a usage example extracted from the [correlation test 
case](http://svn.apache.org/repos/asf/ode/trunk/bpel-test/src/test/resources/bpel/2.0/TestCorrelation/testCorrelation.bpel):
 
 
+    :::xml
     <receive name="receive1" partnerLink="request" 
portType="wns:testCorrelationPT"
              operation="request" variable="request" createInstance="yes">
        <correlations>
@@ -128,7 +130,7 @@ Here is a usage example extracted from t
 
 The first assign initializes the probe parts with the input message. The 
second one places in probeName the text that should be appended. After the call 
to the probe service, probeData will contain both information appended. Then to 
return the probeData at the end of the execution:
 
-
+    :::xml
     <assign name="assign2">
        <copy>
                <from variable="probeInput" part="probeName"/>
@@ -145,7 +147,7 @@ The first assign initializes the probe p
 
 The returned data is finally tested by using a nice regular expression for the 
response:
 
-
+    :::text
     response1=.*Event Start Test5.1 -&gt; loop on receive until message 
includes requestEnd = yes -&gt;
                 received message -&gt; process complete.*
 
@@ -157,7 +159,7 @@ A complete usage example can be found wi
 
 When invoked, the fault service (as the name says) will return a fault. It's 
mostly used to test fault handlers and compensation. To invoke the fault 
service just use:
 
-
+    :::xml
     <invoke name="throwTestFault" partnerLink="fault" 
portType="flt:faultMessagePT" operation="throwFault"
             inputVariable="fault" outputVariable="faultResponse"/>
 


Reply via email to