SAP Archives » Page 29 of 33 » Musings of an IT Implementor

“Fix” Control and ORA-00940: invalid ALTER command

Upon startup of an Oracle 10.2.0.4.0 database I received Oracle error:
ORA-00940: invalid ALTER command

I eventually managed to narrow this down to a “_fix_control” setting.

The database is for an SAP system and the init.ora was updated after following SAP note 830576 (Parameter recommendations for Oracle 10g).
I noticed that I had misread the note and applied a “_fix_control” parameter setting for a slightly (only by a patchset update) higher version of Oracle.

Take care when reading this note and make sure you test the startup and shutdown of the database before going home!

UPDATE: This is a bug. See here.

SAP PI Channel Stopped by Administrative Task

During a routine message mapping using the Java stack with a custom Java class lookup that accessed an RFC communication channel (configured in the Integration Directory), the mapping was failing with multiple errors.

One of the errors stated: “com.sap.aii.af.service.administration.api.cpa.CPAChannelStoppedException: Channel stopped by administrative task”.

Whilst not completely obvious what the exact problem was, I check the CPA cache in transaction SXI_CACHE and ensured there were no errors during a full cache refresh.
No problems there.

So I moved on to check the communication channel itself. All seemed fine. Using the “check” option from the pull down menu, showed all was well.
No other errors.

Restarting the message from SXMB_MONI resulted in the same error over and over.

The resolution:
Simply editing the RFC communication channel in the Integration Directory and changing it to “Inactive”, saving and applying, then changing it back to “Active” (on the Advanced tab), saving and activating.
This seemed to fix the problem.

Looks like the RFC channel destination hostname was modified and this caused the adapter to throw a slight wobbler, making it think it was inactive.

SAP Sender Address for Communication Method

Whilst configuring SAP to send email oubound via SMTP you have to configure the node in SCOT to point to an SMTP server.
Once this is done, you would expect it to just work.
Unfortunatly, you may get the following issue.

When you create a new email message in SO01, you enter the recpient and the message text, then click send, and you are prompted with an error:

The error in the log book says:

“You do not have a sender address in the chosen communication method.“

This was an odd error, but a quick search on SAP notes revealed note 552616.

https://service.sap.com/sap/support/notes/552616

The note mentioned either setting my user’s external email address in SU3 (or SU01), or alternatively, instead of doing this for all users that wish to send external mail, you can set the “default domain” in SCOT.

Set the default domain to something like “mydomain.com”.
This means SAP will create an outbound sender address comprised of the SAP username plus the default domain (sapuser@mydomain.com).

I was then able to send mail externally.

Transporting SAP User Groups

I’ve blogged about SAP user groups before: https://www.it-implementor.co.uk/2011/09/sap-user-groups.html
Let’s say you’ve set them up in your DEV system and now you’re expecing to just transport them. Well, as with all things SAP, it’s never quite that easy.

Create a new workbench transport request in SE01, SE09 or SE10 (doesn’t matter which).
Then open the request at the request level by double clicking it.
Switch to change mode by clicking the pencil button:

Now manually type in the program Id, object type and object names as follows:

R3TR TABU USGRP
R3TR TABU USGRPT

Click Yes at the prompt:

On each item, click the Function button (key symbol):

Enter * in the Table Keys field:

Save the request again.

That’s it!

Release the transport and import into the next system.
This is a farily generic process that can b used to transport any table values.
NOTE: You should be aware that the “*” in the table key, means all items specific to the current client.

What’s in a SAP EHP Anyway…

For some time I’ve often wondered how you can determine what functionality exists in an Enhancement Package (EHP).
I’ve supported SAP ERP 6.00 systems for a while, but I’ve never been involved in the business functionality decisions (I’m a technical guy and this is a Solution Architect’s job).
So it made me wonder, if you were implementing a brand new SAP ERP 6.00 system, how would you determine what level of EHP was right for you.
Well the answer is simple, once I’d done a little reading.

All SAP EHPs are cumulative. i.e. SAP ERP 6.00 EHP 5 includes all the new features included in EHPs 1 to 4, plus some shiny new ones.
So you see, you just need to implement the latest and greatest to get “everything”, then switch it on if you want it. You can use the new SAP BFP (Business Function Prediction) to see what’s in each EHP.

So, why do SAP continue to dish out the older EHPs? or even the base ERP 6.0 release?
Well that is down to software release management and the way that SAP develop the code.
Each EHP is effectively a branch off the main code-set. Each of these branches will need patches, so SAP can’t just kill off EHP 4 when EHP 5 is out. They must maintain the support.
For this reason, you will see why the Support Package Stack (SP-Stack) schedule always has the latest sp-stack for the base release out before the first EHP, before the second and so on.

Like this:
ERP 6.0
-> ERP 6.0 EHP 1
-> ERP 6.0 EHP 2

-> ERP 6.0 EHP 3 ….

The release schedule simply follows the way the support packages are tested and released up through the code-set branches.

The time difference between the base release sp-stack and an EHP sp-stack could be a good indication of the amount of change between the base release and an EHP.

So is there a technical reason why you wouldn’t implement the latest and greatest EHP (as recommended by SAP)?

My answer is YES. I don’t buy a car with everything included, because I know that I can get a SATNAV cheaper elsewhere. Now I guess this depends on your software strategy.
Plus, the more tech you have, the more that could go wrong during application of support patches and upgrades. Lastly, even if you’re not using the EHP functionality, you still have to apply the code during the patch process, increasing upgrade time.

I maintain, if you don’t need it or want it, why apply it.
This is obviously my view, and the counter argument would be that you have the option of “just in time” enabling of new business functionality. In my experience, even the decisions take longer than the actual implementation time, even without “just in time”.