Created attachment 33329 [details]
project exhibiting problem

Dennis is the original owner of this logic.

For invoke one more check should be applied:
pattern "request/response/request-response" idicate propertyAlias that 
should be defined for property in CorrelationSet.

This issue with original description is invalid.

But in reality the problem exist. So I fixed the problem.
Please see invoke :
        <invoke name="InvokeCreateTroubleTicketByValue" partnerLink="TTServer"
operation="createTroubleTicketByValue" portType="ns3:JVTTroubleTicketServant"
inputVariable="CreateTroubleTicketByValueIn1"
outputVariable="CreateTroubleTicketByValueOut1">
            <correlations>
                <correlation set="CorrelationSet" initiate="yes"
pattern="response"/>
            </correlations>
        </invoke>
Correslation "CorrelationSet" have attribute pattern="response".
This means that correlation is applied for INBOUND message.
invoke have TWO variables :
inputVariable="CreateTroubleTicketByValueIn1"
outputVariable="CreateTroubleTicketByValueOut1"

We need to check presence propertyAlias for property with inputVariable message 
type ( due attirbute pattern="response").

This is declaration for variable :
<variable name="GetTroubleTicketByKeyIn1" 
messageType="ns3:getTroubleTicketByKey"/>

Here declarations for property and propertyAlias :

    <bpws:property name="troubleTicketPrimaryKey" type="xsd:string"/>

    <bpws:propertyAlias propertyName="tns:troubleTicketPrimaryKey"
messageType="ns0:createTroubleTicketByValueResponse"
part="parameters">
       
<bpws:query>/createTroubleTicketByValueResponse/return/troubleTicketPrimaryKey</bpws:query>
    </bpws:propertyAlias>
    <bpws:propertyAlias propertyName="tns:troubleTicketPrimaryKey"
messageType="ns:getTTMessage" part="getTTMessagePart">
        <bpws:query>/getTroubleTicketByKey/arg0/troubleTicketPrimaryKey</bpws:query>
    </bpws:propertyAlias>

You can see that there is no propertyAlias declaration for
ns3:getTroubleTicketByKey messageType.

This example should be corrected with changing pattern attribute to "request".
In this case issue will be correct.
For this issue I have introduced fix.

Please let me know if I'm incorrect from your point of view.

Ads, as you observed:
 ... Correslation "CorrelationSet" have attribute pattern="response".
This means that correlation is applied for INBOUND message. ...

This is correct. However the variable associated with the INBOUND message is 
the one that is specified by the "outputVariable". So the original description 
of the bug is correct.

I encountered another similar bug when the correlations are defined on the 
<reply> activity. I have attached the project 
TroubleTicketBpel_Reply_Correlation.zip. Simply open the project and build to 
see the error.

Created attachment 33428 [details]
Project which has the correlation defined on reply activity

I don't care about inputVariable/outputVariable attributes actually.
Mentioned rule here doesn't check variable values.
It just check input/output in corresponding operation.

But you are right here about "request/response" value for pattern attribute.
"request" value is used for outbound message. So in this case I need to check 
INPUT type for operation. In the case of "response" I need to check 
OUTPUT type of operation.
Here part from specification:

In the case of <invoke>, when the operation invoked is a request/response
operation, a pattern attribute on the <correlation> specification is used to
indicate whether the correlation applies to the outbound message (“request”),
the inbound message (“response”), or both (“request-response”).

Now please follow the rule SA00049 for correspondance between inputVariable
and outputVariable.
This rule for invoke is :

When the optional inputVariable and outputVariable attributes are being used in
an <invoke> activity, the variables referenced by inputVariable and
outputVariable MUST be messageType variables whose QName matches the QName of
the input and output message type used in the operation, respectively, except as
follows: if the WSDL operation used in an <invoke> activity uses a message
containing exactly one part which itself is defined using an element, then a
variable of the same element type as used to define the part MAY be referenced
by the inputVariable and outputVariable attributes respectively.

May be you mean the same.


About Reply. There was a bug actually. You are right.
But it was fixed when I close this issue as fixed.
It seems you have used old build for reopening this issue.
Please use for verification last availible build.

I cannot verify this bug as BPEL 1.0, on which the sample project is based, is
not supported in NB6.0.

Close "FIXED" issue against previous releases