Getting Asynchronous Data Requests From Bloomberg®

Thanks to David McKenzie for the workaround suggested in this article.

Be aware that if you start using the BLP Data Control, there is a problem that will keep asynchronous data requests from functioning correctly unless you use a work-around with J-Integra. The problem is that for the Subscribe and GetHistoricalData methods, the Results parameter is declared as [OUT, OPTIONAL] in the Bloomberg® DLL type library. You can only tell the Data Control that you want an asynchronous data return by omitting the Results parameter from the method call.

The VB compiler is smart enough to know that when the [OPTIONAL] attribute is designated, and the optional parameter has been omitted, it automaticaly passes a VT_ERROR variant with the value DISP_E_PARAMNOTFOUND (from C++, you just pass the VT_ERROR variant directly). Apparently VB does not care whether the parameter is an [IN] parameter or an [OUT] parameter.

Using the wrapper method generated by J-Integra, omitting the parameter is not an option because Java does not allow optional parameters - so you must pass null. However, J-Integra does not handle optional parameters correctly if they are declared as [OUT, OPTIONAL]. When J-Integra sees the [OUT] designation, it doesn't do any conversion of the parameter. It is only when the parameter is designated as [IN, OPTIONAL] that a null value gets converted into a VT_ERROR variant.

To get around the problem, you can use invokeMethodByName() to bypass J-Integra's parameter type checking. When invokeMethodByName() is used instead of calling the COM method directly, the [IN] / [OUT] attribute is not checked when sending parameters down the wire. Any paramater that is null will be converted into a VT_ERROR variant.

The following code snippet demonstrates how to do this:

/*
* We can force J-Integra to pass VT_ERROR / DISP_E_PARAMNOTFOUND in the
* results parameter (and therefore convince BlpData to do an asynchronous
* subscribe()) by using invokeMethodByName, which tests for nulls and 
* replaces them with the right kind of 'missing' variants and then shoots
* straight down to the Dispatch code, bypassing all the type checking. This
* is not at all type-safe, but it does work!
*/
Object[] security = {"IBM US Equity", "MSFT US Equity"}; // Array of security IDs (strings)
int cookie = 666; // ID for asynch returns
Object[] fields = {"Bid","Ask"}; // BB Field references (integer) or mnemonics (string)
Object[] params = { security, new Integer(cookie), fields, null, null, null, null };
b.invokeMethodByName("subscribe", params);

If you look at the code inside the invokeMethodByName() method, you will see the conversion of null values to VT_ERROR variants:
public Object invokeMethodByName(String name, Object[] parameters) throws ... {
...
  com.linar.jintegra.Variant variantParameters[] = new com.linar.jintegra.Variant[parameters.length];
  for(int i = 0; i < parameters.length; i++) {
    variantParameters[i] = parameters[i] == null ? new Variant("p" + i, 10, 0x80020004L) : new Variant("p" + i, 12, parameters[i]);
  }
...
}

0x80020004L is the Microsoft error code for DISP_E_PARMANOTFOUND (see winerror.h), and 10 is the enumeration code for type VT_ERROR in the VARENUM enum (see wtypes.h). This is what ActiveX objects expect to get in place of an omitted optional parameter.

Note: For a third-party solution leveraging J-Integra, please see Optura®'s Virtual Investment Analytics (VIA) automation platform. Additional information can also be found here.