cancel
Showing results for 
Search instead for 
Did you mean: 

Generic Interface design

Former Member
0 Kudos

Hello there

I would like to enhance the existing interface in our landscape and make it easy to manage and develop. My Idea was to create a generic interface for all vendors to send their invoices to SAP system. My thought was to create a generic web service on PI which any vendor can call to send their invoices as attachments. PI then determines what kind of invoice it is and posts it into SAP (  idoc or RFC ) .

What pros and cons do you see for this type of approach? Interested to know your views on this.

Thank you

Accepted Solutions (1)

Accepted Solutions (1)

rajasekhar_reddy14
Active Contributor
0 Kudos

The idea looks good and you can use write a condition in interface determination to differentiate which mapping to call(RFC/IDoc).But if the load is high and if you are getting multiple parllel requests at a time means then you may face some problems.

I woud prefer touse individual scenarios so that error handling would become easy and can reduce interface errors too.

Best Regards,

Raj

Answers (5)

Answers (5)

rajasekhar_reddy14
Active Contributor
0 Kudos

Few more cents,

If your interface is Async then if you already have a generic request structurure then writing interface determination definetly works.(we had done for Proxy to multiple tagets) scenario by writing condition in Receiver determination.

But is it is sync scenario then i strongly recomend to use different interface.

If you use one generic structure then Sender system has to write complex logic at their end and condtion logic also in Interface determiantion/Receiver determination becomes much complex.

Best Regards,

Raj

Former Member
0 Kudos

Thanks everybody . I guess the disadvantages outweigh the little benefits. It is an Idea which goes in the direction of service enablement ( SOA)  etc.. but in real life its not as good as it sounds.

rajasekhar_reddy14
Active Contributor
0 Kudos

SOA approach really good architecture but you have to develop your development with broader picture .

But in your case SOA not helps you to get more benefits(my view).

iaki_vila
Active Contributor
0 Kudos

Hi Venkat,

I agree with Baskar,

If i understand right, a few cents:

Cons

1. Lost of transparency. When you provide a web service, you help your web-service consumer to avoid if  you are finally using a RFC, IDOC, JDBC, etc on the receiver side. Your consumer must know if you will go to use a RFC or IDOC, what happend if you change the receiver interface later?, the systems depend from each other more.

2. Monitoring more complex. You sender interface is the same for a lot services, you should think when a call fail how determine what is the corresponding message. If you need stats of the interfaces, etc you don't know really where services are more used.

3. PI Security, Now you could use a service security at service component or sender agreement, If you use the same sender service component you lost the possibility of filtering the user. (This can be avoid with different sender service component).

Finally i dont like so much the idea becasuse it seems to me a way to bring the exchange issue to the sender like the old drivers or connectors.

Regards.

former_member184681
Active Contributor
0 Kudos

Hi,

In addition to what Raja already mentioned: you could use the Enhanced Receiver Determination concept described here to determine the receiver: http://wiki.sdn.sap.com/wiki/display/SI/Step+by+Step+guide+to+Explain++Enhanced+Receiver+Determinati.... Also, bear in mind that this sort of solution is security-vulnerable and you should think how to make sure your final solution is secure enough. Definitely don't think of avoiding sender-side authentication, as people sometimes do.

Regards,

Greg

baskar_gopalakrishnan2
Active Contributor
0 Kudos

I would think more about cons while designing interface.  My answer is NO for the following reasons.

a) is this scenario sync or async? If sync, you need to use BPM. For that reason, I might use seperate interfaces and rather make the interface simple.

b) Due to requirement change for one customer and if you make change web service definition, you might have to forcefully update all the customer to change their webservice client logic to point latest WSDL

c) Webservice interface has limited clarity in error handling. So it is better to go with individual interface.

d) Even if your scenario is async, How do you send back business errors to the sender systems without BPM?

The problem is not with high volume messages, PI is going to treat every message as same whether it comes from sender a or b. 

This is my opinion.