CUA - redistribute default values not working

[krysta_osborn]

Hi everybody,

We are setting up a development CUA environment, and it's talking to our development systems fine. I can create and change users, assign roles, etc. I set the default values (except for time zone) to redistribute in SCUM, but whenever I change them in the child system, they don't distribute back to the CUA.

I checked that we've got an RFC connection going both ways. I'm pretty sure the communication user has the right access. I'm not seeing anything in ST01 or ST22.

What am I missing?

Thanks!

Krysta

Edited by: Krysta Osborn on Nov 4, 2010 9:42 PM

[Former Member]

Change the user type from communication to system and try again. There are very small differences (beyond passwords).

Also check BD87 and SCUL for status of processing.

Happy Idoc diwali...

Julius

[krysta_osborn]

I checked the user, and it's already system. Apologies for not being clear in my original message. I'm not getting anything in BD87 or SCUL. I would've expected an outbound IDOC in the child system, but there's nothing.

Krysta

[Former Member]

Dear guru,

Note that ST01 only has diwali on the application server instance you activate it on!

Switch servers in Sm51 and activate it on all servers to see whether the processing the Idocs sent back cannot be received or processed?

Cheers,

Julius

[Bernhard_SAP]

>

> . I would've expected an outbound IDOC in the child system, but there's nothing. 

In the child theer will not be an outbound idoc, as the redistribution to central system is performed by direct RFC.

So it is essential, that this back connection works properly. Often there are small errors, which cause the whole thing not to work, for instance wrong client set, wrong server set, etc.

Also check SCUM in child system as well, i have seen cases, when parts of the definition have been missing in child system (whole tabs have been missing...).

b.rgds, Bernhard

[Former Member]

BTW: Did you set everything to redistribute in SCUM??

I suspect that your intention is only to make the local child system data (available roles, etc) known to the CUA, or am I mistaken here?

Either way, you should run a full text comparison at least once from the master (to make roles and profiles known to the USL* tables).

Cheers,

Julius

[krysta_osborn]

I have not set up everything to redistibute in SCUM. I've only set the fields on the Defaults tab except for time zone to redistribute. Pretty much everything else is global. Parameters and local lock / unlock are set to local. I checked the setup in the client systems, and all the tabs are there with the values I expect to see.

It looks like the system is trying really hard to send my changes back up to the CUA, but it's just not making it. There were some authorization issues showing up in ST22, but I've got those sorted out. I'm not getting any more dumps anyway. I checked that the RFCs are working in both directions, and they are. So here I am so close and yet so far.

What can I use to look at what's going on inside the RFC? I set an RFC trace in ST01, but the output doesn't seem very useful. I also tried activating a trace inside the RFC and looking at the file it generated. That was horrible, too - lots of data that doesn't mean anything to the unitiated.

Krysta

[Former Member]

Hi Krysta,

Sorry I had misread your name as "Krishna" hence the Diwali Festival comments. Sorry about that, but happy Diwali anyway

The RFC trace in ST01 is different to the authorization trace. Yes, it will give you some information on the target system side but not authorization focused.

Please activate the authorization check-box in ST01 and trace again.

I assume that in both directions you have RFC users in the connections and you logical system names match the RFC connection names and on the "Logon & Security" tab in SM59 there is no "Authorization for Destination" literal entered? (although this is very usefull...)

Plan B: From the test environment of SE37 execute a test case with the same data in it in debug mode. For this you would need to temporarily change the user type to SERVICE and add some S_DEVELOP display authorizations to step through the code and into the remote call to switch into the context of the remote user to see what is going on there.

Note that if the RFC user is not authorized in the master to process all further (logical) child system distribution then the RFC's do not commit any of the work. You can easily test this from SE37 and look at the return messages.

Are you using S_USER_SYS or S_USER_SAS?

Which authorizations for these two objects does the RFC user have?

Cheers,

Julius

Edited by: Julius Bussche on Nov 5, 2010 10:44 PM

[krysta_osborn]

I was wondering what the Diwali reference was about! Now it makes sense.

I checked our RFCs, and the names do match. We also have ALE in the authorization for destination literal. I'll have to ask our Basis what that means, but it sounds like it's a good thing from your reply.

We are using S_USER_SYS. It had assign access to start with. I tried adding distribute and copy but still got a whole lotta nothin'. I'm flattered that you think I know the function module to test in SE37, but I haven't a clue. The last time I debugged something or wrote any code was in SAP R2.

Have a lovely weekend. "See" you back here on Monday.

Thanks!

Krysta

[Former Member]

Then you will need to authorize the RFC user to calll the "ALE" literal destinations as a client in the RFC call., which is the server of your redistribution, to be able to access the targets of the CUA master.

Object S_ICF will help you further. Please check this and S_RFC_ADM authorizations to display these destinations.

In this case the RFC user is a "stepping stone" from the child dialog end user to use the master to call further RFCs via the same destinations as you use for the central maintenance in CUA master, right?

If central maintenance is still working, then there is probably some program or config error which speculation from here is hard to solve.

Mostly I have sympathy with the Global Active Support folks in SAP when it comes to these (possible) config errors.

Cheers,

Julius

[Bernhard_SAP]

>

Krysta Osborn wrote:
> What can I use to look at what's going on inside the RFC? I set an RFC trace in ST01, but the output doesn't seem very useful. I also tried activating a trace inside the RFC and looking at the file it generated. That was horrible, too - lots of data that doesn't mean anything to the unitiated.

Hi,

checked already SM58 in the child system?

Check also Scheduler status in SMQS. Set option 'W/o tRFC X " for the destionation pointing to the central system.

b.rgds, Bernhard

[krysta_osborn]

Turns out that you need to have the data in the central system set up the same as the child system for it to replicate correctly. So if you set a printer in the child system, then that printer needs to exist in the central system as well. Duh!

[Former Member]

Do you want to redistribute it to the central CUA and further on to (all) other child systems?

You could have mentioned that it was printer related....

Cheers,

Julius

[krysta_osborn]

I think the printer issue was causing the other fields not to work because nothing was being redistributed back to the central system. So I thought it just wasn't working.

Your question is a good one. I think it would make sense to push the defaults back out from the central system. Unfortunately, setting this up in our production environment has been preempted by projects that will benefit real users so it may be a while before I get to come back to it. : \

Thanks for checking in!

Krysta