Why is KOFAX SAP Function Module Z_DICOM_STORE_USING_FB60_FB65 not being Populated when Run?

We have upgraded our development SAP system from ECC6 SPS3 to ECC6 SPS5.

An application external to SAP (KOFAX - a SAP certified product) passes an invoice image and invoice data to the SAP system. It then calls the Function Module Z_DICOM_STORE_USING_FB60_FB65 (supplied by KOFAX) in order to store the image on the SAP Content Server and trigger a workflow.

Before the upgrade of the SAP system, this worked, now it does not. An exception is raised within form check_and_add_delimiter (subroutine pool SCMS) which is effectively called from function module SCMS_ARCHIVE_INFO_GET.

The exception is raised because when class method CL_GUI_OBJECT->CLASS_INIT is called, the flags:

• GUI_IS_RUNNING
• ACTIVEX
• JAVABEAN
• WWW_ACTIVE

are set to blank values.

This happens when the process is kicked off from the KOFAX GUI. If I run Z_DICOM_STORE_USING_FB60_FB65 from transaction SE37 and populate the structures with the same data, the image is stored and the workflow is triggered.

Please can you suggest why the flags are not being p开发者_StackOverflow社区opulated when the program runs?

Thanks.

This is a "technical duplicate" of you other posting. Again, the issue is clear - the "KOFAX GUI" appears to use a RFC connection to call the function module, but the function module then uses some other stuff that requires not a RFC connection, but a full-blown SAP GUI at the other end because it tries to access SAP GUI attributes. I'm not into CMS, so I can't help you to figure out why this was changed during the upgrade...

For most scenarios a normal RFC connection is sufficient, SAP GUI is only required if you try to execute BDC within the function module (e.g. for "direct posting"). Since you say that it worked before I can only assume that this is not the case.

Could it not be that the error happens during the upload of the image? Maybe the upgrade did something to the content server configuration? There is a test program for the content server that you can run.

This was resolved by one of our develpers. The answer he gave me was:

We modified check_and_add_delimiter (subroutine pool SCMS) in order to overcome this problem (we effectively stopped the bit of offending code from being called)