Most people are somewhat familar with how K2 blackpearl does logging and how we can tweak the various logging options.  However, debugging in K2 connect is a somewhat less well known area.

Over here, I am going to cover some tips on the common logging options.  This can be used when tracing down K2 connect issues during execution with an SAP backend.

Common issues are:

1. SmartObject calls do not return the expected data or any data at all
2. SmartObject calls just fail without any meaningful messages

In terms of troubleshooting, the following will help:

1. Default K2 blackpearl console logging will show what is happening on the K2 server end.  You should be able to see when the SmartObject call is executed (and any errors if any).
2. SmartObject Logging is helps us to see what data is being passed in at the SmartObject level to the K2 connect service broker level.  You can see the input and output results of the data packages.  This was extremely useful in a certain case where a customer expected certain data to be returned from a BAPI call but different results were being returned.  In the end, the SO logging showed that the return call was returning an array of records (whereas the developer thought it was a single record).
3. Protocol Logging shows what BAPI calls are being made and also some statistics about them.  You can turn this on via the K2 connect Administration Tools under Settings.  Check the Enable Protocolling option and click OK.  After this is done, restart the K2 connect service.  You will see the BAPI calls being called in the Protocol console in the same admin tool panel (click Protocol).
4. RFC exception log gets created if there is an exception at the RFC layer.  This is quite useful if the SmartObject calls fails with a connection error message (and the K2 connect service is running).  This is the last place to check if all the previous logging options don't give any clues on the failures.  You can find this text log in C:\Windows\System32\dev_rfc.trc.  Note that extension seems to indicate a SQL profiler trace file but it isn't.  Use Notepad or a similar editor to view it.
5. [Update 23 Dec 09] ABAP Debugging - If you have the SAP Gui installed on the designer machine, can you try turning on ABAP debugging (reference http://www.sap4u.org/media/userfiles/articles/pdf/26.pdf). Basically, this is pretty useful to step into the BAPI call to see what is happening on the SAP side.  This allows us to see whether the call is being executed properly and also whether it returned any results.
6. [Update 23 Dec 09] Testing with ERPConnect code - Sometimes, you can get strange errors with some particular BAPI calls.  This can fail even at the Test Cockpit side.  This might indicate an issue on the ERPConnect layer (which K2 connect uses).  To verify, you can write a simple ERPConnect to do the call and see if it works. You can find samples under the Start -> Program Files -> ERPConnect -> Samples (There are relevant samples for VS2003/2005 and 2008). Basically, the idea here is to see if the issue is related to K2 connect or the the ERPConnect layer.  Either way, in cases like this you need to log a support ticket with K2 support.  Determining where the issue lies will make it easier for support to get this routed.
    

Ok, this wasn't a very long post but I hope this helps to condense the various troubleshooting options you have when working with K2 connect.  If you have anything to add, feel free to send in your comments.

Cheers.