SoapDoc::Init: Cannot set inout buffer

A while ago I was setting up some SOAP connectors for our BI guys. I went into the SICF transaction and activated the connectors they needed.

They called me back, complaining that they would get this error message in the SOAPUI:

<p>URL http://xxx.xxx.xxx:yyyy/sap/bc/soap_sap-client=zzz call was terminated because the corresponding service is not available.</p>

I investigated. I tried to go to the webpage and see if it would return anything to me. I went into my browser and disabled the "nice error messages" option, so I could see it all. I then went to the URL and found:

 

My users immediately complained that "there's an error - Look it says cannot set inout buffer, the problem must be in the ICM, you fix it". But I didn't actually call the interface with any data. So it was just returning what it was asked.... An XML with absolultely nothing in it. Sending data through the interface would make the error go away.

Lesson learned: A "nice" error message is problematic, but a misleading one isn't any better ;)

SPAM queue unable to reset after phase IMPORT_PROPER

You know it, I know it, SAP knows it.... We all make a few mistakes once in a while. The other day I apparently messed up a SPAM queue updating some support packages.
"no worries" I thought, I'll just reset the queue and start all over. but noooo. SAP stops me from that. Errors like:

You cannot reset the queue from import phase 'IMPORT_PROPER'

immediately hit me..... Annoying. However, I remembered a little trick I did a while ago (yeah, so I dont really learn NOT to make mistakes, I only learn to clean up after myself):

1)  Clear data in the TP buffer, this can be done by renaming the buffer file in /usr/sap/trans/buffer (or whereever the bufferfile is located)
2)  Run the command tp r3i all <SID> pf=<path to TP_DOMAIN_.PFL file> tag=SPAM –Dclientcascade=yes –Drepeatonerror=8
3)  Go to SAP and run transaction se37 and enter the function module ocs_reset_queue, hit F8 and apply parameters IV_TOOL=SPAM and IV_FORCE=x
4)  Now the queue is nice and clean....


Downside is ofcourse that doing this might leave you with an unstable system. But if the alternative is a restore, then I'll personally be happy to try this first.Though next time I think I'll try to spend some time to figure out how to forcefully complete the queue instead. That could come in handy if I fail during the DDIC_ACTIVATION phase instead.

HTTP error: 400 Bad Request, no connection to docbase - Archivelink isn't working

The other day we had to move some servers around. But when we were done functional testing showed that an archive link in OAC0 was defective. It showed up with the error

HTTP error: 400 Bad Request, no connection to docbase 'docsap': No repository

I was puzzled, in that we didn't really move the tomcat running the connection. Moving the calling database shouldn't cause this problem either.
It took a while, but after some investigation, we found that this error was preexisiting in our system. So no luck running through the changes.
I looked at the SAP side of things, and the connection hadn't changed in a few years, so it wasn't a change. It had to be a bug. I tried moving the archivelink to the development server. It worked like a charm. So not a bug in SAP then.
As an error 400 meant that an error was received (in this case "no repository") The tomcat service was responding. I would have gotten an error 404 if it had been down. However, just to be on the safe side, I decided to restart the service. It IS running on windows after all.
No joy. Maybe an undocumented firewall change ?
Again, no joy. I checked the documentum server manager on the machine. The archive was available.
Maybe a config change in the documentum server ? I looked at the configfiles, there were some issues, but nothing that should cause problems like this. I fixed whatever was apparent, and restarted the tomcat again.
No joy. I was getting spooked. Was it a priviledge problem ? I looked at the user rights. They were good.

Given that another installation seemed to work, it HAD to be the tomcat. I was about to make the call and start a reinstallation of the service, when I wondered: "What would be the difference between reinstalling and now....." Then it hit me.... The workfiles !!! All that temporary crap. I entered the tomcats work dir and cleaned everything that had to do with my repository. Then I rebooted the virtual instance, and 5 minutes later..... Error gone....

this makes me wonder, if I restart my service, why is it even bothering to read through the old crap ? But never mind, I just put a nice little cleanup script together and placed it in the startup of the service.