PI SWC Naming convention

[Marçal_Oliveras]

Hello, I've read this SAP [document|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/40a66d0e-fe5e-2c10-8a85-e418b59ab36a] about best practices naming convention and I still don't have a clear idea about how many software components I have to create in 1 scenario.

There are 3 posible ways in the document:

- 1 SWC with all the ESR objects - Not recommended.

- 2 SWC one with the receiver objects and the other with the sender objects. But where you keep the mapping objects??? Always in the sender SWC? Always in the Receiver???

- 3 SWC with receiver, sender and mapping objects respectively. I don't like that solution because I think that the SWC object loses its meaning and you will have all the objects of a simple scenario "spreaded" along the ESR.

Have you an better alternative to help me???

Best regards,

Marshal

[Marçal_Oliveras · Accepted solution]

Thank you for your answers.

It looks like it's really personal to decide which its the better option to define the SWC. I will think about it...

To Madhusudana Reddy and abhishek salvi: I think that organization way it's very clear but if you do that, the SLD is meaningless, because you are using a SWC as a "business area" not as a software, and I'm not sure about it. Maybe the problem is how the SWC object is used in SAP PI.

To Patrick Koehnen: I think that the 3 SWC approach is too much confusing too, and the 3rd SWC with the mappings it's not really a "software" of our landscape....

[Shabarish_Nair · Accepted solution]

My personal choice is option 3 i.e to have SWCV per systems and a common SWCV for the common objects across systems.

This clearly helps demarcate the flow and with the use of the namespaces and folders, you can easily organize the ESR.

We have used this in multiple projects and it had always been beneficial in understanding the ESR in a better way when it eventually comes to an App support perspective.

[Marçal_Oliveras · Accepted solution]

But then, if you use the option 3, don't you think that SAP must create a new object type for the ESR called something like "Mapping component" to allow us to develop our mappings in a meaningfull object?

What's your opinion about this?

[Former Member · Accepted solution]

Hi,

you could use a SC and give at a meaningful name.

For example if you want connect a legacy system "LEGACY" with an ERP system.

Then you can create first a Product in SLD called "LEGACY CONNECTOR" and then one or multiple SCs for your scenarios within this product.

I guess the best approach is to have some naming conventions for this kind of SCs. For example always use the word CONNECTOR or PI_CONTENT.

Regards

Patrick

[jagdishwar_b]

>>3 SWC with receiver, sender and mapping objects respectively.

This is the best option i used, and maintenance, representation becomes much easier.

I_SWCofSender

I_SWCofReceiver

A_SWCVofMappingObjects

the first two SWCVs, you can visualize as sender and receiver applications.

within the third swcv A_SWCVofMappingObjects, you can use namespace to classify different scenarios. It can contain Message Mappings, Interface Mappings, and Process Integration Scenarios.

thanks,

BJagdishwar

[Former Member]

Hi,

I prefer approach 3 (with 3 swcs for a scenario).

More information could be found here:

/people/alwin.vandeput2/blog/2006/06/07/d-xie-soap-part-4-xi-software-component-architecture-for-point-to-point-scenarios

/people/thorsten.nordholmsbirk/blog/2006/07/25/structuring-integration-repository-content--part-1-software-component-versions

Regards

Patrick

[former_member200962]

 1 SWC with all the ESR objects - Not recommended.

Different SWC for different business units/ business flows can be an option.....a detailed explanation can be found in this thread:

Regards,

Abhishek.

[madhusudana_reddy2]

Hi Marshal,

I also gone through that document, it is very confusing and not feasible to follow. Putting sender side data type in one SWC and receiver data type in Other SWC and mapping in other SWC is some complicated to follow and understand. So you follow your approach like below...

if the interface related to purchasing create software component and put all namespaces related to purchasing under this software component

if the interface related to SALES create software component and put all namespaces related to SALES under this software component

.

.

.

. etc.

thanks,

madhu

[Former Member]

We currenlty use approach 2. Mappings stored in Sender SWCV.