Wednesday, August 27, 2014

SMQS scheduler status shows RES_LACK

Today I was confronted with the fact that our BI system wasn't reciving data from our R3. After a short investigation, I found that the IDOCs were not processed. Manually processing them sent them to the tRFC queue. However, from here they just ended in "transaction recorded".
From past experience I knew to check the registrations in the SMQS. However, today I was met with a weird situation. The registration was fine, but the scheduler had a weird status.


After a while of looking, I noticed that the "host ID" was that of another system (!)
My suspicions immediately went to last weeks homogenous system copy. So I went through every step of the RFC process, from data creation to the REF destinations. And lo and behold.... the RFC logon groups (RZ12) had not been configured. Simple fix, furtunately.

Monday, August 4, 2014

SAP line opener showing correupted XML file recieved

If like me, you are forced to use an archaeic line opener, that cannot even run as a service. You may on occasion run into problems, and wonder why there is no support to get. And in truth I cant tell you. Sometimes I get angry and just continuously ping the sapserv1 server, and then go home, knowing that things are working, but saddend by the fact that it's not running optimally.

However, at least one function I have managed to find a solution for. I frequently got the error:

Error: 04-08-2014 09:44:38: Function startProcess : Corrupted XML file received
Error: 04-08-2014 09:44:38: parseXML: non-XML file
04-08-2014 09:44:38:  begin of make_https
04-08-2014 09:44:38: Getting SAPRouter data for LOP in the SMP

I tried reinstallting the LOP, I tried using a different user, I've tried pretty much anything, but it never worked. Untill I found out that it was caused by the company proxy. Not that the proxy itself poses a problem, but the way SAP tried to connect, isn't entirely compatible with modern proxies (You will know this if you have ever tried to replace a SAP webdispatcher with a real reverseproxy).

So how did I resolve the problem ? Simple. I just logged into the SAP marketplace from the server running the LOP. Then the proxy information is passed correctly by IE, which also means the LOP wont have to.