cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with sandbox

Former Member
0 Kudos

Our basis people created a GTS sandbox from a copy of our production environment and an ECC sandbox which was a copy from our production ECC environment.

They have created the logical systems etc and I have assigned them to my logical system group.

When I try and run the jobs for material/customer changes the jobs fail. I'm getting a number range error but number ranges have been maintained.

Also I tried creating an order in the ECC sandbox but got a message that the number range for the custom product wasn't maintained but the message takes you to the number range in ECC but the config is really in GTS where it is maintained.

I noticed that in the copy some of the config was missing from the plug-in. I have reconfigured what was missing went through the number ranges, doc types etc., but still getting errors.

Accepted Solutions (1)

Accepted Solutions (1)

former_member215181
Active Contributor

Hi Chris,

These are typical symptoms of the problems in copying GTS clients.  If you haven't already done so, please support my posting in the Idea Place for a "toolkit" to assist with this.

I think the problem here is that the Master Data still belongs to the original Logical System Group (as assigned to your Production client).  You'll need to ask your Basis team to use Transaction BDLS to substitute the new value in tables /SAPSLL/PNTBP and /SAPSLL/PNTPR.  And look out for any other tables in use that also use the LSG as a key (you can find them in the Data Dictionary).

Hope that helps.

Regards,

Dave

Former Member
0 Kudos

Hi Dave,

I took a look at your posting and would definitely support it but I have a question. When I execute the BDLS transaction you mentioned  it seems to want to change logical system names which makes sense since they data was created in a different logical system.

But the /sapsll/pntbp table, only contains the logical system group name. In my case I put the ECC and GTS sandbox's int he same groups I was already using.

Should I have created a new logical system group name for both the ECC ad GTS sandbox's?

It seems that my issue would be more around the fact that the data was created in a different logical system.

Thoughts?

Just an FYI I had our basis group run BDLS but I am still getting the same errors and I cannot transfer master data.

former_member215181
Active Contributor
0 Kudos

Hi Chris,

No, don't create a new Logical System Group.  I don't yet have any further suggestions, but perhaps you could let us know exactly which error messages are being raised in each situation?

Regards,

Dave

Former Member
0 Kudos

Dave,

I have a Word document with screenshots of the errors but I can't post it here.

Any ideas?

former_member215181
Active Contributor
0 Kudos

Hi Chris,

Simply expand slightly on your first posting.  For example where you say: "I'm getting a number range error", please expand to: "I'm getting error /SAPSLL/CORE_LEG 999" (or whatever it is).

Alternatively, if you're feeling artistic, you could insert the screen-shots in your reply.

Regards,

Dave

Former Member
0 Kudos

Ok well when I try and transfer a material from ECC to the GTS sandbox I get a popup saying of 1 selected material 0 were processed.

When I check the log SLG1 there are two error messages.

The fist says" Transfer of attribute; not possible table is blocked. when I double click this it references missing number range for custom products. These are maintained in GTS (Although when you double click on the message it brings you to ECC number range for custom products which is not relevant.

The second error below that says:

Internal error is program object: /sapsll/API_6850_synch (RC=2) processing terminated.

I created an order in ECC sandbox then tried to transfer to GTS sandbox and the pop up says:

SAP GTS: Legal Control: Doc type mapping not maintained

Again this all configured

I hope this helps.

Also when I try setting the jobs for change pointers the material one runs for 60 seconds and fails where as the customer one runs and runs.

Former Member
0 Kudos

So more info. So I went and double clicked on the error message for material transfer related to the number range issue it was showing in the log for the material transfer.

As noted it brought me to ECC config for that number range which was empty so I created the number range and the transfer says it was successful.

I restarted the change pointer job for material master changes and it now runs successfully, but it didn't send over the change to the material I had made.

I went back and transferred it through the ECC plug in as an initial transfer and it said it was successful and so does the SLGI log but when I check the product master in the GTS sandbox the change isn't there and the changed on date was from when the initiial transfer was in our production environment.

Even though the SLG1 log in the ECC sandbox says the material transfer was successful the material log in GTS under System Monitoring shows nothing was transferred.

former_member215181
Active Contributor
0 Kudos

Hi Chris,

Glad to hear of your progress.  Unfortunately I haven't any more immediate suggestions, or time to look into it for the next day or so - perhaps others can offer advice?

Regarding the "failed" Material transfer; did you check (in table BDCP or BDCP2) that a Change Pointer had actually been created prior to the run?  And if so, did the status get changed by the run?  If so, is there a log in Transaction SM58 to explain the failure?

Regards,

Dave

Former Member
0 Kudos

Dave,

Thanks for taking the time to respond. I've gotten a little farther. Yes the change pointers are getting created and then marked as processed in BDCP2, but the transfer doesn't happen.

I tried running SM58 with just my user ID but there were no entries.

I'll continue to investigate. At this point I think my message types and change pointers are working properly.

mouaz_benredjeb
Contributor
0 Kudos

Hello Christopher,

Sometimes, after a system copy, the RFC destinations are not correctly updated.

In your case, may be your ECC sandbox is trying to "talk" to a GTS other than the GTS sandbox.

In order to check, in ECC, could you please go to transaction SE37, type function module name '/SAPSLL/RFC_DEST_GET_R3' and then hit F8 twice.

Is the system pointing to correct GTS system ?

Regards.

Mouaz BEN REDJEB

Former Member
0 Kudos

Hi Mouaz,

I ran the function module and it shows it is connected to GTS correctly.

A couple things I've noticed. As I mentioned earlier, material transfers are creating change pointers and the status does get changed to processed after the change pointer job runs. When I look at the SLG1 log in ECC it says the material transferred but none of the changes are making it to the GTS sandbox.

With customers I am having some issues. If I make a change to a customer a change pointer does get created but it never gets processed. The change pointer batch job runs and runs and never completes.

If I look at the SLG1 log in ECC sandbox for customers it gives the following error:

No data selected from table /SAPSLL/TCOPAO
mouaz_benredjeb
Contributor
0 Kudos

Please have a look at transaction SLG1 in GTS.

SLG1 contains a lot of logs... For material transfer related logs, use transaction /n/SAPSLL/PRODUCT_TLSH (in GTS).

Former Member
0 Kudos

Mouaz,

I have checked the logs in GTS and they are all empty for both the material and customer transfers.

Looking at table /sapsll/TCOPAO the required entries are there.

mouaz_benredjeb
Contributor
0 Kudos

Can you please check following things:

- In ECC, transaction SM58, leaving user ID empty (or fill it with *) and selecting the destination RFC of your GTS system. Have a look as well leaving the destination RFC box empty just in case.

- In GTS, transaction ST22 to look for any dumps there.

- In GTS, transaction SM12, to look for any table lock that prevents data to be updated

Former Member
0 Kudos

No dumps

mouaz_benredjeb
Contributor
0 Kudos

OK. What is the data that you are changing in Material Master in ECC and expect to see replicated to GTS ?

Former Member
0 Kudos

I normally change a few letters in the description for the material and the name1 when transferring a BP.

When I do that for each a change pointer does get created and I see them in BDCP2.

When I run RBDMIDOC for each the change pointer status for the material says that it was processed but the change doesn't make it to GTS.

For the customer the change pointer status never gets set to processed and nothing transfers.

Regarding sales orders when I create a sales order in ECC and save I get an error saying:

SAP GTS: Legal Control: Doc Type Mapping Not Maintained

but all of this config is there in the GTS sandbox.

mouaz_benredjeb
Contributor
0 Kudos

Well, how are your debugging skills ?

former_member215181
Active Contributor
0 Kudos

Hi Chris,

Make sure that the mapping for Document Types is ONLY done for the Logical System Group, (not also for the Logical System), or for the Logical System.

Otherwise, as Mouaz says, I think we're at the stage where you will need to run the transfer in debug mode and find out what is going wrong.

Regards,

Dave

Former Member
0 Kudos

Dave and Mouaz,

That is the conclusion I have come to. I do have the authorization to debug but I will work with one of the developers hopefully this afternoon to see what is going on.

Dave, yes the doc types are assigned at the logical system group level and this config came over with the copy so I don't understand why I am getting the error.

mouaz_benredjeb
Contributor
0 Kudos

Hi Christopher,

Few tips for you to debug with your developer:

- You can test the initial transfer of materials as it is a bit easier to test than through Change pointers

- For the initial transfer of materials, make sure that the user-exit SLL_LEG_PRR3_002 is deactivated or the coding in commented in order to not filter any material transfer

- For the initial transfer of materials, set a break point in FM /SAPSLL/MATMAS_MASS_R3, more or less around line 85 where the FM /SAPSLL/API_6850_SYNCH_MASS is called (This is the RFC call). Make sure that the initial transfer stops at this break point and make sure that the FM tables contain all the data of the material you want to replicate

- If the RFC call is reached and processed, just after have a look at variable lv_msg_text. This can give you hints on the issue.

Keep us posted on what you find with the developer.

Regards.

Mouaz BEN REDJEB

Former Member
0 Kudos

Mouaz,

Thanks for the reply I really appreciate you and Dave's help. Yes we are using the initial transfer of materials to debug but I am only using one material that I know is fine and won't get filtered.

So far in our first attempt to debug we stopped at the place where it calls GTS and it did find the correct GTS sandbox, but even though it finds that and the change pointers seemed to get processed correctly it still doesn't transfer.

Somehow I still think that ECC sandbox is not recognizing the GTS sandbox because the error messages that I am getting point to tables in ECC that are really GTS tables like /sapsll/tcopao.

mouaz_benredjeb
Contributor
0 Kudos

I really recommend you to deactivate or comment all user-exit code that can mess with the data transfer.

Sometimes, just changing the sort order of internal tables in the user-exit ends up messing with the data transfer.

Aswell, if you have access to SM59, check that the GTS destination RFC is correctly set up.

former_member215181
Active Contributor
0 Kudos

Hi Chris,

For the Business Partner, could you please try changing the Tax Number or VAT number, instead of the Name?

I'm wondering if there's some conflict with Address Management (so choose a field that definitely comes from table KNA1, not ADRC).

Regards,

Dave

Former Member
0 Kudos

OK the issue is resolved. I'm not to happy with the basis guy right about now but at least the problem is fixed. When I looked in SM59 at ABAP connections I never looked at the details until today since I saw the GTX logical client listed and assumed it was OK.

When I looked today I noticed there was no target host assigned so I asked him if that was correct.

His response was short and that it's fine that way.

A few minutes ago he sent me an email stating to try again and now everything transfers correctly.

Of course he didn't admit that I was correct because now when I go to SM59 and check there is a target host assigned to the GTS sandbox logical system

former_member215181
Active Contributor
0 Kudos

Hmmm.  Well, glad that you got it fixed.

Dave

Answers (0)