Why are callbacks sometimes skipped?

Question

Hi All,
BPEL      10.1.3.1
OS      Linux
I have question about why an asynchronous BPEL process, called ServiciosRed, would report the following:
"Skipped callback "RespuestaSR" on partner "client"."
I understand that if this process had been called directly from a webpage/BPEL console, then this expected, but in this case this process is being called by another BPEL process residing in the same environment.
ServiciosRed supports multiple operations and is called several times by the parent as shown below:
Parent Flow
... (1)
<invoke name="SR_BajaAddons" partnerLink="ServiciosRed" portType="ns13:ServiciosRed" operation="Addons" inputVariable="SR_Addons_InputVariable"/>
<receive name="Respuesta_SR" partnerLink="ServiciosRed" portType="ns13:ServiciosRedCallback" operation="RespuestaSR" variable="Respuesta_SR_InputVariable"
createInstance="no"/>
... later on in the flow (2)
<invoke name="Migracion_KPN" partnerLink="ServiciosRed" portType="ns13:ServiciosRed" operation="Evolucion" inputVariable="Migracion_KPN_InputVariable"/>
<receive name="Respuesta_SR" partnerLink="ServiciosRed" portType="ns13:ServiciosRedCallback" operation="RespuestaSR" variable="Respuesta_SR_InputVariable"
createInstance="no"/>
... later on in the flow (3)
<invoke name="SR_AltaAddons" partnerLink="ServiciosRed" portType="ns13:ServiciosRed" operation="Addons" inputVariable="SR_Addons_InputVariable"/>
<receive name="Respuesta_SR" partnerLink="ServiciosRed" portType="ns13:ServiciosRedCallback" operation="RespuestaSR" variable="Respuesta_SR_InputVariable"
createInstance="no"/>
In (1) the parent receives the response.
In (2) the parent DOES NOT receive response - and I see the "Skipped callback..." message when I view the sub-flow
[I manually supplied the response using the interactions tab]
In (3) the parent receives the response.
What is causing the skipped behaviour? In the past I have simply created a new partner link for use @ (2) and the issue appears to go-away - But I shouldn't have to do this - right?
Thanks - Anit

Answer 1

Yes! Variants are great when you are trying to write code that must operate on many different data types. However there are caveats that make error handling more difficult and critical. Take a look at the OpenG LabVIEW Data Tools, which make Varaint usage practical. This library is part of the OpenG Toolkit.
LabVIEW Data Tools Presentation - variants, run-time type checking, and data manipulation design patterns
Examples:
Get Object Attributes as XML
<
A HREF=http://www.openg.org/tiki/tiki-index.php?page=EXAMPLE%20-%20OpenG%20Flatten%20to%20XML>OpenG Flatten to XML
Python Client to LabVIEW Server
Universal Probe