Gen GUI C application passing BLOB (document data) to external .NET DLL

Products

• Gen
• Gen - Workstation Toolset

Issue/Introduction

In a Gen Windows GUI C application currently use the Gen Toolset INVOKE statement to call a method from a .NET DLL to pass a document reference (a GUID identifying the document).
Need to change this process to pass the document data itself (up to 2MB) as a base64-encoded BLOB

As an interim solution currently looking at doing the data transfer via local files.

Considering these other technical options:

• Define a method in the DLL that the Gen Toolset can match to a BLOB
  
  
• Obtain a WSDL for the web service available from the DLL and use the Gen CALL EXTERNAL feature to consume it.
  NOTE: Creating a RESTful web service and using Gen CALL REST to consume it is not feasible because due other reasons the Gen 8.6 PTF level cannot be at a level where the CALL REST feature has been added.

Is there any further advice on those?

Environment

Gen 8.6 Workstation Toolset
Gen 8.6 Window GUI Client application

Resolution

Options:

1. The developer is looking at trying to create/expose a new method on the .NET DLL to accept a BLOB and use the INVOKE statement in a similar way to pass a BLOB attribute view.
   If the .NET method exposes a stringArray or a byteArray, the method does not appear in the OLE object browser. If it exposes a string the developer could match only to character views, not BLOB views. This may be because the developer had not enabled BLOB processing at that stage and will be retested after a BLOB view is available again.
   
   
2. If a SOAP web service can be created on the .NET DLL then the Gen CALL EXTERNAL feature can be used.
   CALL EXTERNAL supports sending a Gen BLOB to either of these XML types for outbound view matching: base64Binary, hexBinary, String. That is per this doc. page: Add a Call External Statement > XML Types
   That would seem to be the most graceful and also most "up to date technology" solution if it can be achieved on the DLL side.
   Currently the DLL exposes an .aspx file and developer will attempt to expose an .asmx file to generate a WSDL which they can then use to confirm whether it can expose a SOAP web service.  

The solution using local files to do the data transfer is working and at this stage the other options above were deferred.