cancel
Showing results for 
Search instead for 
Did you mean: 

ICO and standard scenario Query

r_s_kulkarni11
Participant
0 Kudos

Hi All,

I have one tricky query as follows.

My scenario is Idoc (Z idoc and standard also) to JMS we have this interface in production for one country. we have many scenarios of this kinds.


Now we are implementing the scenario for another country where the receivers are different, so I want to know if I can create an ICO and proceed with the scenario or should I use the old objects only (mainly Receiver determination) and modify them or I can still use the ICO?

Is it a good practice to use ICO in my condition or not?

Thanks in advance.

Regards

Rahul Kulkarni

Accepted Solutions (0)

Answers (3)

Answers (3)

engswee
Active Contributor
0 Kudos

Rahul

Whether classical or ICO, the possibility also depends on the IDoc partner profile setting in your sender system.

For ICO, the sender system will require a new IDoc port with a different RFC destination as the one used for classical scenarios.

Creating Receiver Ports on the Sender System for Processing Java IDocs - Advanced Adapter Engine - S...

Will the sender system be able to differentiate which port/partner profile to use when sending the IDocs?

What partner types are used for the IDoc in the sender system - Logical System (LS), Customer (KU), Vendor (LI), etc?

Rgds

Eng Swee

r_s_kulkarni11
Participant
0 Kudos

Hello,

I have different ports and partner profiles.

I am having a second thought, is it ok if I use the Idoc as message type instead of using it as interface and I can create a new service interface with this Idoc type as my message type?

I mean My idoc is Orders05 then for 2 interfaces I will create int1_out and Int2_out and inbound interface as int1_in and int2_in and then I will assign the idoc type as message type to all these interfaces, so all the objects will be different.

Will it be good practice to do?

Regards,

Rahul Kulkarni

engswee
Active Contributor
0 Kudos

Hi Rahul

For outbound IDoc interfaces, what you plan to do will not work (assigning IDoc as message type in new service interfaces.) The runtime will always resolve the IDoc reaching PI into the standard IDoc imported definition - it will never use any custom service interfaces.

Yes, you will and should have different partner profiles, but of what partner types - LS, KU, LI?? If you do not have this information, please ask your ABAP/IDoc team. Without this it is hard to determine whether you can switch from classical to ICO for new interfaces. And if not, then it might be best for you to just stick with the existing design/practice.

Rgds

Eng Swee

former_member192343
Active Contributor
0 Kudos

ICO possible only for adapters at Java Stack side. If you will use Idoc AAE, then it is possible, but if you have PI 7.1 version, you not have IDoc AAE.

r_s_kulkarni11
Participant
0 Kudos

Hi,

I have PI 7.31 Dual stack....

Yes I will be using IDOC_AAE what I want to know is will it create a conflict in PI if same IDOC type is getting used in ICO and the classical scenario?

former_member192343
Active Contributor
0 Kudos

I think, PI will not allow you to crete ICO while you have old objects with the same parameters of sender agreement. Try to create and you will see.

r_s_kulkarni11
Participant
0 Kudos

Hi,

while creating ICO, there will not be any previous sender agreement of same type as in classical we do not need sender agreement for IDOC right?

Former Member
0 Kudos

Hi Rahul,

Yes, you need to delete the existing sender agreement from the existing standard scenario that you have before you can create the ICO. The sender agreement of the standard scenario cannot co-exist with the new ICO.

Kind Regards,

Jenny

Former Member
0 Kudos

Hi Rahul,

Which version of PI are you using? With your scenario which iDoc is the sender, it is not possible in PI 7.11. But in PI 7.3, it is possible.