Improving Interface design

[Former Member]

Hi all ,

I need your suggestions in improving the current interface design.

We have an interface: Sending System--->(JMS Adapter) PI 7.1(IDOC) --> (Idoc)ECC

-

---

This is the current situation:

Sending System sends 1 file with 1000 transactions, out of which 70% gets filtered in PI and sends nearly 300 idocs to ECC.

Right now we have this interface for 1 company code. Few transactions should give out DELIVERY idoc and few should give out MBGMCR idocs.

Few Fields like MESSAGECODE, MESSAGEFUNCTION, MOVETYPE, etc in the IDOCS etc. have complex udfu2019s.

UDFu2019s have the logic based on 6 incoming fields(companycode, Transaction, Supplier, PO,ReturnComp, DirectWithdrawal)

2 Message mappings- one for MBGMCR and 1 for DELIVERY

In receiver Determination.. we are doing routing based on company code.

In Interface determination, we have a complex condition for MBGMCR (based on 5 fields)which is taking 3 times more than mapping execution time (Mapping-2 sec and Interface mapping condition check takes 6 sec).

-

---

New Business Requirement:

Now the business wants us to develop a prototype which will reduce extensive testing when new conditions are added. So they want more flexible solution as this interface will be taking care of the further rollouts where new plants and conditions will be added. While adding new conditions business is worried that the existing logic shouldnu2019t be affected and retested.

So few options which came into picture are:

1. Maintaining a database table where a table will be updated with conditions. In PI we will do a look up to check the incoming values match the values in table and return the corresponding output values.

Consequences: Due to large volumes sent everyday nearly 500,000 messages a day . Each msg containing 1000 transactions out of which 70% gets filtered in PI. So we expect 500,000 RFC calls will lead to performance issues in PI.

2. Filtering Transactions on the sending system & sending some kind of flags (for transactions to be processed) which will reduce filtering in PI and save lot of system resources also. But this is not feasible from business point of view.

-

---

So now the question is :

Is there any other better way to avoid retest of the currently existing logic when new conditions are added .

(keeping performance in mind.)

Your suggestions are highly appreciated.

(I know this a lengthy post. But Thanks for your time and for your valuable suggestions)

[former_member200962 · Accepted solution]

While adding new conditions business is worried that the existing logic shouldnu2019t be affected and retested.

honest opinion would be the person who does the re-config needs to be more careful and not touch the existing mapping/ routing conditions etc.

there is no other way wherein you can say that shield part1 of the MappingA while somebody makes a new change to the same mapping.

If your fear (or of the business') that it may happen that even existing logic is deleted while making new one then as a workaround you can suggest that we can easily retrieve the old logic (object)...at least when it comes to ESR/ IB.