SWCV

[Former Member]

We are trying to build a Best practices of Defining a Software Component Versions and the Name spaces.

Any particular Blog that narrates about this.

1)In my SWCV1 I have two Name SPaces one for SENDER and other One for RECEIVER.

If I Create the Data Types and Message Types, message interface for

SENDER & RECEIVER in the corresponding namespaces , now whether it

is possible for me to create the message mapping

in the RECEIVER Name Sapce?

2) If I have two SWCV , SWCV1 and SWCV2

and Sender Namespace in SWCV1 and receiver Namespace in SWCV2

If I Create the Data Types and Message Types, message interface for

SENDER & RECEIVER in the corresponding namespaces , now whether

it is possible for me to create the message mapping

in the RECEIVER Name Sapce?

[justin_santhanam · Accepted solution]

Pete,

Generally the namespaces will not be created for sender and receiver. It will be created for particular business scenario.In that namespace you will be defining your objects.Hence from my point of view creating namespaces based on sender/receiver is not correct. Its my suggestion.

Best regards,

raj.

[Former Member · Accepted solution]

Jai , thanks for your answer.

Raj, your point is valid.

I am not going to create sender and Receiver Name spaces. Just for convenience I said like that. You can take namespace 1 and Namespace 2.

[former_member182412]

Hi

In our company we created one software component for all scenarios the name is company name, and for each scenario we created one name space. so we got one software component and more than one namespaces. I think this is the best way to create DT,MT,MI,MM,IM under same namespace, there is no confusing to search for objects in same scenario. transporting the objects also it is very easy because it is under one software component version. It is very easy to read all the interfaces.

Praveen.

[Former Member]

Hi ,

Here is the scheme ...which you can use if you find it usefull

Here we indentify the swcv on the basis of interfaces ..like for senders or legacy you can have one swcv1 ...so basically if you have a file interface ....you can import your xsd here as external defintion ...namespaces can be made scenario specific.

Now for all reciever interfaces / imported objects you can have another swcv i.e. swcv2 ...

Finally where you will specify mapping between these two interfaces ...

from swcv1 and swcv2 ...you can have swcv3 which by the way has depencies in sld defined on swcv1 and swcv2..

This way maintaince becomes easier ...let's just say you are adding a new field ..you know you have to make changes in your interface present in swcv1...

...and mapping change swcv3..

This way ..for a large number of intefaces ...you can neatly arrange under these swcv so they become more readable.

Regards,

Deepak

[Former Member]

Hi,

but, creating sender_swcv + receiver_swcv + mapp_swcv seems to be against the concepts of component organization in XI. All the component tree is there even if you don't have data types or other components in a swcv, so, I can think the way you are expected to develop the things are all there, as in the sap sample scenarios.

We are using exactly this approach today (sender_swcv, receiver_swcv and mapp_swcv). By our experience, this approach is no good... Let me explain why.

If you have an integration scenario like Legacy -> XI -> Abap proxy, probably the same incoming message will be sent to abap proxy. In this scenario, if you have swcv1_sender, swcv2_receiver, swcv3_mapp, you will need to build the message type on the swcv1_sender, copy it to swcv_receiver (this is the worst!!!), and make a mapping 1 to 1 in swcv3_mapp because de sender and receiver namespaces need to be different (is not possible to create same namespace in different swcv). Otherwise, if you use only one swcv to build all the scenario, you will see so more simple it is! You will need only one message type, no message mapping (because is the same message for sender and receiver), and when you need to change anything there is all there in the same swcv!

regards!

roberti

Message was edited by:

Waldemar Roberti

[Former Member]

Hi Roberti !

In fact, there is NO NEED TO COPY the objects from sender_swcv and receiver_swcv to the mapp_swcv..you need to define<b> usage dependencies </b> in SLD. mapp_swcv should have usage dependencies of sender and receiver swcv..in that way in Integration Repository, all sender and receiver objects will be available in the mapp swcv namespaces.

Regards,

Matias.

[Former Member]

Hi

I didn't mean to copy to swcv_mapp, the copy in the scenario I explained is about sender_swcv and receiver_swcv. Keep in mind that in this scenario (legacy -> xi -> abap proxy) there is no need of a mapping, because the message can be the same (if it is in the same swcv and namespace for sender and receiver).

regards!

roberti

[Former Member]

Hello,

I would create SWC scenario-based. In your case I would create just one SWCV and then different namespaces below. I would recommend one namespace just for the data types, message type, the "data base" of your service in some company-wide model. Then different namespaces for each system/application/web service where you collect the message interfaces and the mapping interfaces, eventually data types etc., too (esp. when using legacy systems this will be necessary).

The advantage of this procedure is that you always know where to look for your components - you will mostly look for them knowing on what system they are used. It helps you when transporting proxys, too, when you run different applications on one system.

Of course, this requires a good modelling in XI, some kind of meta structure where you map all things to and from.

This is just a suggestion, there are other possible divisions of the namespaces, too, like inbound/outbound, synchronous/asynchronous, depends more on the landscape you're working in.

Regards,

Jörg

[Former Member]

Hi Jörg,

I don't agree that it "depends more on the landscape you're working in", as you said. Integration scenarios have always a sender and a receiver. Based on this, I think it is possible to discuss about a model to organize the development for all kind of integration scenarios and for all kinds of landscapes.

I would really appreciate if this thread could be more discussed with your experts experience. I think the organization of development in XI is not very clearly explained in the documentation, so, we only "suppose" the way that SAP architected the XI to develop integration scenarios.

regards!

roberti

[sridharreddy_kondam]

Hi Pete,

Let me explain you...

The best way to create SWCV and corresponding objects is should be like this...

Create 3 SWCV's ... one for the Source System( Source DT,MT,MI)

one for the Target System(Target DT, MT,MI)

and the Third SWCV(Say Processess SWCV) is for Messsage Mappings and IM's and Integration Scenarios... ...

This is the best way to handle in the real time scenarios.....

Regards,

sridhar reddy

[Former Member]

Thanks.

So let us say if we have 3 Legacy system and One ECC component, you are recommending me to create

5 SWVC ( 3 for Legacy Systems, 1 for Ecc Component and 1 for Interface mapping and Message Mappings)

And Inside my SWVC for ECC I need to create a Namespace for each application say for AccountsPayable, General Ledgers, HR, etc.

Whether you guys agree with me.

Thanks a lot friends.

[sridharreddy_kondam]

Hi Pete,

Yes it is the best way to create one SWCV for each System..

Here You have to create 5 SWCV 3 for legacy, one for ECC and the other for MM,IM..

and also for each type of Processing it is better to create seperate namespaces...

Regads,

sridhar

[Former Member]

If we are going to have a Separate SWCV for the the Message Mapping and Interface Mappings won't cause extra burden when we do a Transport?

Rather limit with one SWCV for each of the System and try to do the MM and IM in one of the Sender or receiver system consistently? Whats your opinion?

thanks.

[sridharreddy_kondam]

Hi Pete,

It may be done in any one of the SWCV ... but it will be difficult to identify each of the interfaces if we have N number of interfaces for N number of Legacy and SAP R/3 systems...

So going the way with seperate SWCV makes good sense and also easy to identify the Interfaces involved for each type of System...

and MM and IM i agree its easy for the transport also..

Regards,

sridhar

[Former Member]

Sridhar, I am not clear with your point.

Do you agree my point or Disagree my point?

thank you

[justin_santhanam]

Pete,

What happens if you have 100 of interfaces in your implementation. Then u have to create 200 namespaces , isn't it? Pete, it will be a big mess. Don't close the thread wait for more suggestions.

Best regards,

raj.

[Former Member]

Hi Pete !!

Maybe another approach is to create 3 SWCV. One for the sender, with data types and other objects that are exclusive for this software component. Then another SWCV for the receiver, with the same criteria, and then a third SWCV, for the scenario itself that contains objects that are related to both SWCV (sender and receiver) => message mappings, interface mappings, templates, etc....

Regards,

Matias.

[Former Member]

Hi,

Mapping can be done in either sender or receiver.

[Former Member]

Yeah, I agree with Raj.

We created our SWCV definitions by this way (on namespace for sender, another for receiver and another for mapping). Another definition was about the SWCV, we create one for Mappings (a neutral component), one SWCV for each one legacy application integrating with SAP and another one to each SAP component involved into any integration scenario. It was very good when we didn't have experience with XI objects and all... now we know it is not a good way of doing it, specially about the namespaces and the Mapping SWCV.

A good way about namespaces would be to create canonical schemas and use it in your scenarios. The problem here is I still don't know how to put the canonical schemas into a place (probably a namespace like http://mycomapany.com/schemas) that could be used at all scenarios... we are searching for this right now. When I found I will post it here.

About SWCV, you can choose if you will put the mapping on the sender or on the receiver side. If you put in different places for each scenario, it will be confusing and difficult to find...

regards.

roberti

[Former Member]

Have a look into

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

BTW, Answer for your question 1 and 2 is, <b>yes</b> you can

Regards,

Jai Shankar