SRM system showing approval mail with saphtmlp link

The other day, one of my colleagues came over to me and asked my why our approval emails sent out to all the managers had a weird logon link in them
I logged on to the system and said, "what do you mean ?". As I saw nothing wrong.

"Well", my colleague replied, "when I look at the properties of the mail in SOST or SOSG, it contains a lot of weird stuff in front of the actual address, but when I remove that it works".

I looked, and I saw what he meant. There was a reference to the sap HTML viewer, even the approval link had the sapevent infront of it. And the reason for sending out these mails was exactly to be able to send them to someone without access to SAP. I pondered this for a while, and I looked at notes, read documentation. Then it occured to me - But if we hadn't changed this in the last 6 months, then why had noone complained ?
So on a hunch that SAP would render this differently in SOST than after transmission, I asked my colleague to get a hold of a mail from one of the recipients. And lo and behold, SAP DOES infact render this differently when viewed from within the SAPGUI. The links were perfectly created in the mails people recieved.
Note to self: Ensure the ability to test as an end user.....

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.

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.

Logical system name for this BI is not allowed

Following a homogenous systemcopy of our BI, we were following the normally outlined strategy from SAP regarding copying BW/BI systems, in SAP note 886102.
In this case, however, a successfull, albeit very fast run BDLS job, resulted in the following error message when attempting to rename the logical system. Even SAP were unable to provide a timely solution to the problem.

This was, in retrospect ofcourse caused by the fact that the BDLS job only LOOKED successfull, but in fact stopped after only a few tables. One of the tables was ofcourse the T000 (which meant that the client would try to use a logical system name which didn't correspond to the technical name), aswell as the DBLS table(s). So everything looked to have finished ok. There also wasn't any error messages.

The trick was, how could I see that the job actually hadn't doen what it was supposed to ? BDLS runs for other logical systems ran just fine, and this had never been an issue in the past. I had to run a debugging of the BDLS transaction.

I had in the past had many discussions with a colleague about the BDLS functionality. I said there was a dynamic program containing the fields to be converted, he said that all fields defined as "logsys" would be converted. It turned out We were both only partly right. There IS a program, which creates a dynamic mapping of all the fields containing the logsys. And then the conversion starts based on this BDLSMAP. However, there apparently isn't any controls available to determine if this mapping fails. and in my case it did.

So I ended up finding a service program for the BDLSMAP that could clear the mapped data, After running that, the BDLS run finished fine, and all of our logical system problems went away. I'm seriously considering if this program, RBDLSMAP_RESET shouldn't ALWAYS be run prior to a BDLS run.

Selected system is not a quality assurance system

The other day my developer colleagues started reporting problems with them being unable to release transports for testing. the STMS_QA transaction was throwing an error.  

I immediately looked at the STMS configuration, and found that the system attributes for the QA system did not have a checkmark at "delivery after confirmation". So I logged into the domain controller, set the checkmark and redistributed the configuration. That should have been the end of it.
But lo and behold, it didn't work..... I logged on the the QA system again and had a look, the changes wasn't distributed, even though I pressed the button (!!!). Luckily the "adjust with controller" DID grab the configuration from the controller...

That fixed the problem. Now to figure out why the distribution didn't work.....