cancel
Showing results for 
Search instead for 
Did you mean: 

Turn Off UK related Interfaces

Former Member
0 Kudos

Dear All,

I have UK & US related Communication Channels separately. Now this is the time to turn off only UK related Channels in the landscape. All are Idoc--File & File ---Idoc Interfaces only.

I can Turn off Inbound( Sender) Channels by "Inactive" option from sender file adapter.

But how can i turn off Outbound Interfaces from SAP to Legacy system that involved as Idoc to File scenario???

If i do "Inactive" in Receiver Communication Channel, it will go and sit in system Error.

Regards

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Bhavna,

Assuming you are reusing the ESR part for UK and US interafces and some field in idoc field determines teh reciver.

there are 2 options i can see

1) filter the UK data from distribution model.Check with ABAPer , i guess its possble for standard Idocs only.

2) Remove / change the condition in reciver determination

this approch is lilttle risky as.. it is not a good practise to change the interface ditrectly in production.

you can do it but , have to be very careful and make sure that once the job is done u revert this.

3) Ask legacy system not to poll the NFS/FTP folder. And assuming that u have to turn off the UK interafce till X- date.. ask basis to remove the files till X-date

but i guess.. it is always better to stop the messages in the source system...call is yours.

Regards

BiplaB

markangelo_dihiansan
Active Contributor
0 Kudos

Hello,

Even if we can control or block by using XPATH in Receiver Determination, messages will still be persisted in PI, which would not be the ideal solution for this....

Yes, that is why you need to alter the behavior of the system when a receiver is not found from Error to Ignore. This way, when the xPath condition is not met, the message processing stops for that message without giving any red flags (errors).

Is there something we can do in the ABAP stack of XI to block it before it reached the Messaging system , though, ideally the solution would be to have the job be blocked in SAP ECC..

SInce it is triggered via idoc, stop the message in the first step of the pipeline, namely receiver determination.

Regards

Mark

Edited by: Mark Dihiansan on Sep 8, 2011 7:44 AM

Former Member
0 Kudos

> Yes, that is why you need to alter the behavior of the system when a receiver is not found from Error to Ignore. This way, when the xPath condition is not met, the message processing stops for that message without giving any red flags (errors).

>

> SInce it is triggered via idoc, stop the message in the first step of the pipeline, namely receiver determination.

>

> Regards

> Mark

>

First, let me thank for your input..

Even if the message are not flagged "Red" , they will still be persisted, right? If so, cant we avoid it ?

Ideally, there should not be message record visible in the Monitor, for such messages. Isnt' it?

Thanks & Regards,

XA

markangelo_dihiansan
Active Contributor
0 Kudos

Hello,

Even if the message are not flagged "Red" , they will still be persisted, right? If so, cant we avoid it ?

Ideally, there should not be message record visible in the Monitor, for such messages. Isnt' it?

If by persistence you mean it will stay in the db until it is deleted (same with the case of successful messages), then yes. If the idea of persistence is retrying, then no, the messages will not be retried.

As for the messages not being seen in moni, I guess this is unavoidable because the message (idoc) gets sent directly to the integration engine pipeline.

Hope this helps,

Mark

Former Member
0 Kudos

Thanks ! I got an idea

Regards,

XA

Former Member
0 Kudos

Ask SAP Team to hold the jobs which triggers IDOC to XI .

Former Member
0 Kudos

We can do that as one option, is there any other options that we can do in XI????

We don't have any Jobs for few interfaces, what can we do for those??

Regards

Edited by: Bhavana Ch on Sep 7, 2011 11:08 PM

Former Member
0 Kudos

i belive there should always be a change pointer to trigger idoc to XI .

For Sender IDOC scenarios , control is always with SAP system , either they can remove the partner profile or the stop the programs which trigger IDOC

markangelo_dihiansan
Active Contributor
0 Kudos

Hello,


We can do that as one option, is there any other options that we can do in XI????
We don't have any Jobs for few interfaces, what can we do for those??

If you are using xPath for receiver determination, then you can just remove the conditions and receivers that satisfies for UK interfaces. Just make sure to select the option Ignore If No Receiver Is Found so that the messages will not go into error and will not persist. But this is not the best approach, correcting it from the sending side is the best.

Hope this helps,

Mark

naveen_chichili
Active Contributor
0 Kudos

I agree with Mark you can edit xpath ...please check this [Link|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3774] [original link is broken] [original link is broken] [original link is broken]; for ref.

Former Member
0 Kudos

Hi

Even if we can control or block by using XPATH in Receiver Determination, messages will still be persisted in PI, which would not be the ideal solution for this....

Is there something we can do in the ABAP stack of XI to block it before it reached the Messaging system , though, ideally the solution would be to have the job be blocked in SAP ECC..

Regards

XA

Former Member
0 Kudos

Thanks a lot guys for your valuable discussions here.

I agree on the decision of remove message type entries from partner profile itself, so that no Idoc will reach XI and not even Idoc will generate.

Regards