XI problems BP not created

[Former Member]

Hi experts

I am using standard scenario MM-SUS and all is configured and working, but when I send vendor from R/3 to SUS not errors are find in SXI_MONITOR, SM58 and SMQ2, but for some reason the Business Partner is not cretaed in SUS.

Please someone could help to solve it.

Thanks

Nilson

[Former Member · Accepted solution]

?Hi!

I do not know that sceanrio. Is it RFC- or IDoc-based on R/3 side?

If RFC-based check transaction SM58 in R/3 system.

If IDoc-based you can also use transaction WE05 to check whether Idocs have been created and whether they have been sent successfully (IDoc Status Code).

Can you see the messages in SXMB_MONI, that is messages were created and handed over from R/3 to XI?

If so please check the Adapter/Communication Channel Status using RWB. What technology is used to send data to SUS? SOAP, IDoc, RFC or whatelse?

Regards,

Volker

[Former Member · Accepted solution]

Hi Volker

The scenario is R/3 - XI - SRM SUS, An Idoc is generated in R/3, sent to XI and after to SUS, so between R/3 AND XI adapter is IDOC, and between XI and SUS, adapter is XI Proxy, All works fine the Idoc is generated sent to XI and out of XI succesfully, no problems in SXI_ MONITOR in XI side and SUS side, but Business partner is no created, no logs exist.

I don't know where can I look, maybe in SPROXY but I am not sure.

Thanks

Nilson

[Former Member · Accepted solution]

Hi Nilson!

So technically everything is fine, but not BP is created in SUS. To find out what really happens in SUS you may do the following:

Activate trace in SUS for the technical user used for calling the proxy using transaction ST01. Additionally activate SQL trace using transaction ST05.

After that send an IDoc, then turn off all traces and have a look at them.

You will see potential problems concerning Authorization as well as which tables have been accessed (READ, UPDATE, INSERT etc.).

Then come back to this thread and tell us what you see ....

Regards,

Volker

[Former Member · Accepted solution]

Hi Volker

I could see that after ST01 and ST05 traces, I had problems in TABLE BUFFER TRACE, several tables are listed with problem.

What does it means?

How could I solve it?

Thnaks

Nilson

[Former Member · Accepted solution]

Hi!

Can you copy&paste the trace output to this thread?

What about ST05? Did the system try any UPDATE, INSERT, MODIFY operations, and if yes, what was the return code of database?

In ST01 trace no authority problems occured?

Regards,

Volker

[Former Member · Accepted solution]

Hi Volker

For all errors the return code is 64.

Following you can see some details about he trace

Mandante: 700 Usuário: XIAPPLUSER Transação 1CB8B1DD3428F1F0A5F600188B47D18F

Proc.operac. 1 PID Data: 13.11.2008 Início:17:20:30:193.322Fim:17:20:30:211.982

Primeiro bloco da etapa de diálogo Último bloco na etapa de diálogo

Dimensão bloco: 4512 Nº de registros: 18 Versão de file: 1

hh:mm:ss:ms Tipo Dur.(us) Objeto Texto

17:20:30:193 BUFF 8 BGRFC_CUST_O_SRV Prog: CL_BGRFC_CUSTOMIZLinha: 75 Buffer: RCad.pesq.

17:20:30:193 BUFF 2 BGRFC_CUST_O_SRV Prog: CL_BGRFC_CUSTOMIZLinha: 75 Buffer: RCad.pesq.

17:20:30:193 BUFF 2 BGRFC_CUST_O_SRV Prog: CL_BGRFC_CUSTOMIZLinha: 75 Buffer: RCad.pesq.

17:20:30:193 BUFF 1 BGRFC_CUST_I_SRV Prog: CL_BGRFC_CUSTOMIZLinha: 1.003 Buffer: RCad.pesq.

17:20:30:193 BUFF 1 BGRFC_CUST_I_SRV Prog: CL_BGRFC_CUSTOMIZLinha: 1.003 Buffer: RCad.pesq.

17:20:30:193 BUFF 0 BGRFC_CUST_I_SRV Prog: CL_BGRFC_CUSTOMIZLinha: 1.003 Buffer: RCad.pesq.

17:20:30:194 BUFF 8 LCRT_CLNTCACHE Prog: SAPLLCRACCESS Linha: 92 Buffer: RCad.pesq.SRD700 _SERVER

17:20:30:194 BUFF 3 SXMSPFCOMPONENT Prog: SAPLSXMS_PF_COMPOLinha: 310 Buffer: RCad.pesq.

17:20:30:194 BUFF 6 SXMSPFCOMPONENT Prog: SAPLSXMS_PF_COMPOLinha: 310 Buffer: RCad.pesq.

17:20:30:194 BUFF 0 SXMSPFCOMPONENT Prog: SAPLSXMS_PF_COMPOLinha: 310 Buffer: RCad.pesq.

17:20:30:194 BUFF 6 TFDIR Prog: SAPLSUNI Linha: 3.109 Buffer: PCad.pesq.SPI_AGENT_TRFC_EXECUTE

17:20:30:194 BUFF 2 SSPIAGDFLD Prog: SAPLSPIAGRTL Linha: 85 Buffer: RCad.pesq.700_AG

17:20:30:194 BUFF 1 SSPIAGDFLD Prog: SAPLSPIAGRTL Linha: 85 Buffer: RCad.pesq.

17:20:30:194 BUFF 0 SSPIAGDFLD Prog: SAPLSPIAGRTL Linha: 85 Buffer: RCad.pesq.

17:20:30:195 BUFF 4 TFDIR Prog: SAPLSUNI Linha: 3.109 Buffer: PCad.pesq.SPI_AGENT_TRFC_DEST_SHIP

17:20:30:195 BUFF 2 SSPIAGDFLD Prog: SAPLSPIAGRTL Linha: 85 Buffer: RCad.pesq.700_AG

17:20:30:195 BUFF 1 SSPIAGDFLD Prog: SAPLSPIAGRTL Linha: 85 Buffer: RCad.pesq.

17:20:30:195 BUFF 1 SSPIAGDFLD Prog: SAPLSPIAGRTL Linha: 85 Buffer: RCad.pesq.

Mandante: 700 Usuário: XIAPPLUSER Transação 1BB8B1DDD5EEF1C9A5F600188B47D18F

Proc.operac. 0 PID Data: 13.11.2008 Início:17:20:29:933.815Fim:17:20:29:215.651

Primeiro bloco da etapa de diálogo Último bloco na etapa de diálogo

Dimensão bloco: 3378 Nº de registros: 13 Versão de file: 1

hh:mm:ss:ms Tipo Dur.(us) Objeto Texto

17:20:29:934 BUFF 5 USR02 Prog: SAPMSSY1 Linha: 137 Buffer: PCad.pesq.700XIAPPLUSER DEST_SHIP

17:20:29:934 BUFF 2 USR01 Prog: SAPMSSY1 Linha: 137 Buffer: PCad.pesq.700XIAPPLUSER DEST_SHIP

17:20:29:934 BUFF 21 USREFUS Prog: SAPMSSY1 Linha: 137 Buffer: PCad.pesq.700XIAPPLUSER DEST_SHIP

17:20:29:934 BUFF 2 USR05 Prog: SAPMSSY1 Linha: 137 Buffer: RCad.pesq.700XIAPPLUSER DEST_SHIP

17:20:29:934 BUFF 1 USR05 Prog: SAPMSSY1 Linha: 137 Buffer: RCad.pesq.

17:20:29:934 BUFF 0 USR05 Prog: SAPMSSY1 Linha: 137 Buffer: RCad.pesq.

17:20:29:934 BUFF 3 USRBF3 Prog: SAPMSSY1 Linha: 137 Buffer: PCad.pesq.700XIAPPLUSER DEST_SHIP

17:20:29:934 BUFF 2 AAB_ID_ACT Prog: SAPLIRFC Linha: 6.996 Buffer: RCad.pesq.700XIA

17:20:29:934 BUFF 1 AAB_ID_ACT Prog: SAPLIRFC Linha: 6.996 Buffer: RCad.pesq.

17:20:29:934 BUFF 1 AAB_ID_ACT Prog: SAPLIRFC Linha: 6.996 Buffer: RCad.pesq.

17:20:29:934 BUFF 0 AAB_ID_ACT Prog: SAPLIRFC Linha: 6.996 Buffer: RCad.pesq.700XIA

17:20:29:934 BUFF 0 AAB_ID_ACT Prog: SAPLIRFC Linha: 6.996 Buffer: RCad.pesq.

17:20:29:934 BUFF 0 AAB_ID_ACT Prog: SAPLIRFC Linha: 6.996 Buffer: RCad.pesq.

[Former Member · Accepted solution]

Hi Nilson!

Unfortunately I am not a native speaker in Portuguese ....

You are from Brazil, aren't you?

Would it be possible for you to logon in english and then try to copy&paste the trace output again?

What about the ST05 trace output?

But in the meantime you should in every case try to do the following:

Give user XIAPPLUSER in SUS system client 700 SAP_ALL and SAP_NEW and then try it again.

Then send me the trace outputs.

I'm almost sure this problem is not an XI/PI problem but a SUS problem.

If we should not find the solution, prepare yourself to open a CSN in SMP.

Best greatings from cold and rainy Germany.

Regards,

Volker

[Former Member · Accepted solution]

Hi Volker

Yes I am in Brazil, excuse me for sent it in Portuguese for you.

IN trace log there are no authority problem .

Transaction ? Work process no 0 Proc. Type DIA Client 700 User XIAPPLUSER TransGUID 3FBDB1DD9AB4F126A5F600188B47D18F Date 13.11.2008

Duration Obj. name Op. Recs. RC Statement

7 USR02 READ SI 1 0 P 30 700XIAPPLUSER

2 USR01 READ SI 1 0 P 30 700XIAPPLUSER

2 USREFUS READ SI 1 0 P 30 700XIAPPLUSER

2 USR05 OPEN 0 R 30 700XIAPPLUSER

1 USR05 FETCH 0 64

0 USR05 CLOSE 0 0

16 USR02 UPDATE 0 0 P 30 700XIAPPLUSER

5 DDLBBUFTST DEL DIR 0 64 S 64 EBUSR02

8 USRBF3 READ SI 1 0 P 30 700XIAPPLUSER

5 AAB_ID_ACT OPEN 0 R 6 700

2 AAB_ID_ACT FETCH 0 64

1 AAB_ID_ACT CLOSE 0 0

1 AAB_ID_ACT OPEN 0 R 6 700

1 AAB_ID_ACT FETCH 0 64

1 AAB_ID_ACT CLOSE 0 0

4 SXMSCONFVL OPEN 0 R 6 700

21 SXMSCONFVL FETCH 0 64

1 SXMSCONFVL CLOSE 0 0

1 SXMSCONFDF OPEN 0 R 0

109 SXMSCONFDF FETCH 0 64

0 SXMSCONFDF CLOSE 0 0

1 ASTAT_TYP2 OPEN 0 R 0

2 ASTAT_TYP2 FETCH 0 64

0 ASTAT_TYP2 CLOSE 0 0

3 SSPIAGDFLD OPEN 0 R 6 700

1 SSPIAGDFLD FETCH 0 64

0 SSPIAGDFLD CLOSE 0 0

1 SXMSCONFDF OPEN 0 R 100 RUNTIME ACL_CHECK

3 SXMSCONFDF FETCH 0 64

0 SXMSCONFDF CLOSE 0 0

8 SXMSCONFVL OPEN 0 R 6 700

1 SXMSCONFVL FETCH 0 64

1 SXMSCONFVL CLOSE 0 0

2 USRBF2 OPEN 0 R 50 700XIAPPLUSER S_XMB_AUTH

9 USRBF2 FETCH 26 0 Gets: 26 Dur.: 0

0 USRBF2 FETCH 0 64

0 USRBF2 CLOSE 0 0

2 UST12 OPEN 0 R 50 700S_XMB_AUTH&_SAP_ALL

1 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTH&_SAP_ALL

1 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT-SD13001300

1 UST12 FETCH 0 64

1 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT-SD13001300

0 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT-SD13001301

1 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT-SD13001301

0 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT_BI56000100

1 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT_BI56000100

1 UST12 FETCH 0 64

0 UST12 CLOSE 0 0

1 UST12 OPEN 0 R 50 700S_XMB_AUTHT_BI56000101

1 UST12 FETCH 0 64

[Former Member · Accepted solution]

Hi Nilson!

In this ST01 trace I cannot see any indicators pointing to a potential root cause of your issue.

What about the ST05 trace? Can you find any INSERT, UPDATE or MODIFY operations here? And if so on which tables and with which database return code?

If we cannot find anything here I'd suggest you to open a CSN in SMP (it's a standard scenario and normally it should run out-of-the-box, when all PI configurations are properly done).

Is the content of the message in the local SUS receiver engine also okay? Can you find any footprints in the SOAP Header area of the PI message?

Regards,

Volker

[Former Member · Accepted solution]

Thanks Volker

I have apned a CSN and I ma waiting, In ST05 there are no inserts, updates or modify and the user XIAPPLUSER already have SAP ALL.

Any way thanks for help me.

Best regards from Brazil

Nilson

[Former Member · Accepted solution]

Hi Nilson!

Please let me/us know about the outcomes of your CSN. If there are no "database manipulation" statements within the SQL trace, then obviously nobody tries to write anything to the database. Little wonder that you cannot find the BP in the target system.

By the way: How many degrees celsius do you currently have in brazil?

Regards,

Volker

[Former Member]

HI Nilson

Just to add. check for the condition which creates BP. Is your message satisfying the condition. It is possible that data itself is not valid to create BP and may not be an error in XI or SUS.

Thanks

Gaurav

[Former Member]

Hi Gaurav

How can I check conditions, where can see it?

Thanks

Nilson

[Former Member]

Hi!

I think Gaurav meant: Check the payload of the message in SUS. Is the payload sufficient and intended to create a new business partner?

Does the message have a "target flag" in SUS?

Is it possible for you to change the ABAP proxy in order to find out whether the BAPI call (I think and hope there is a BAPI call to create the BP) throws any exceptions which are catched by the proxy?

If everything does not help, open a CSN at SMP

Regards and greetings to warm and sunny Brazil from cold and rainy Germany

Volker

[Former Member]

Hi Nilson

As Volker said

I was suggesting to check the payload. Does it satisfy your condition to create a BP. With this take the payload and debug the proxy and see if it create BP or not and if not whats the reason.

Sometimes problem is not with XI or R/3 systems its the business data with issue.

If nothing works then definitely you need to open a note on this.

Thanks

Gaurav

[Former Member]

Hi Gaurav

I have checked in payloads of XI side and SUS side and there are diferences between messages, in XI side the message is like in R/3 IDOC but whem it arrives in SUS are missing several fields, so the fields are not enough to create BP.

Some idea why it is occuring?

Thanks

Nilson

[prateek]

Check first in sxmb_moni of XI that mapping output is correct or not? It seems to be either mapping problem or data problem.

Regards,

Prateek

[Former Member]

Hi Nilson!

Now we are coming close to the resolution of your issue. I assume in XI/PI you use the SAP standard scenario for connecting R/3 with SUS, especially the standard message mappings.

If so, open a CSN in SMP. This obviously is a bug in the standard scenario.

If not, you have to check your own mapping for completeness, especially concerning the missing field values in the target message.

Regards form very cold Germany (tonight 1 degree Celsius),

Volker

[Former Member]

Hi Nilson

Are you using standard Integration scenario? Check with all the steps and check all the actions you need to mention with this.

You can test all mappings it will be interface mapping only i think and no message mapping. I think the reason can be you missed to mention some mapping name in IS or ID config. Just verify and then open a note on the same.

Thanks

Gaurav

[Former Member]

Hi Volker

I think we are coming close to the resolution, I found an error in my R/3 idocs, for some reason the idoc structure were not correct after transportation from my DEV to QAS some fields in Idoc was not active, I corrected it and deleted my scenario in Integration Builder and created agaim, but unfortunatelly it is wrong agaim.

The idoc in generated in R/3 with all fields, arrives in XI with all fields but for some reason arrives in SUS without all fields.

Gaurav asked me if is it a standard scenario, yes but I think it's not a bug it's an error caused by the wrong idoc structure.

How can I correct it?

Best regards from Brazil 25 degrees

Nilson