3 SWCV Strategy Design Recommendation

[Former Member]

All,

At my company we've been trying to establish our modelling standard around the 3 SWCV technique and we've currently got a request that's presenting a problem to us. Was wondering if anyone here could help. Here's the scenario.

I've got 1 ERP system which sends an IDoc to XI which will then have to take the data and route it to one of two legacy systems using the file adapter. Now the data types, message types and message interface for both legacy files are identical. So following the 3 SWCV technique I've really got 4 SWCVs lets say we're calling them SWCV_ERP_1, SWCV_XI_1, SWCV_Legacy_1, SWCV_Legacy_2.

We have our send idoc action and our imported IDoc definition defined in SWCV_ERP_1. We had defined seperate receive file actions (1 for each of the legacy SWCVs) and again seperate dt, mt and mi definitions even though they're identical in structure (1 for each of the legacy SWCVs).

In the SWCV_XI_1 we were going to build our integration scenario (using each of the 3 actions defined in our other SWCVs), our message mapping and our interface mapping. Originally we defined it with 1 source interface (the IDoc) with 2 target interfaces (1 message interface from each of my legacy SWCVs). This resulted in us having in our interface mapping 1 source message with 2 mapping programs (one each to map the source to each of the seperately defined message types from the legacy SWCVs).

Our goal was to then in the Integration Directory (we're on XI 3.0) to receive 2 seperate message that we could then use a content filter for each of the messages. For legacy system 1 if a field in the message was a certain value we either sent it or not. Since we received an identical message we would have another filter for legacy system 2 that if that field had a different value then we forwarded it to system 2 (or not).

We haven't got to the ID yet as we're getting a failure when we test the IM we get the message:

"Cannot produce target element /ns0:MT_BLAHBLAHBLAH/YADAYADAYADA. Check xml instance is valid for source xsd and target-field mapping fulfills requirements of target xsd"

Any guidance would be appreciated.

[Former Member · Accepted solution]

k. Thanks everyone. I realize my error as posted was a mapping error. I just wanted to explain (and get an understanding that I've built this properly) why even though my 2 legacy system are using the same file layouts that I still chose to create 2 sets of DT, MT and MI. So even though we're calling it the 3 SWCV method I'm really using 4 SWCV because I've got 2 legacy systems, my XI system and my ERP system.

So because I've modeled it this way and I've got 1 outbound IDoc from the ERP system that has to somehow get seperated into 2 messages I wasn't sure the best way to go about it. Right now the components I'm using are my imported IDoc, 2 mapping programs (one to map the IDoc to system A message type and one to map the IDoc to system B message type). I've tested each mapping program and they both work properly.

In the design for my interface mapping I've got essentially 1 source interface which is the IDoc. I then list 2 target interface (1 message interface for each of my legacy systems). I click the "Read Interfaces" button and essentially it builds my 1 source MT (the IDoc), both mapping programs and both target MT (1 each for each legacy system). When I test the interface mapping is when I get the error message.

Now the structure for message type is:

MT_LEGFILE1_OUT

DT_LEGFILE1

DT_DATA

The occurrences of MT_LEGFILE1_OUT is 1..1

The occurrences of DT_LEGFILE1 is 1..unbounded

The occurrences of DT_DATA is 1..1

The error I'm getting is essentially could not produce target element /ns0:MT_LEGFILE1_OUT/DT_LEGFILE1

The detail of the errors is as follows:

14:08:10 Start of test

Creating mapping sequence with 2 steps.

Creating step 0

Creating Java mapping com/sap/xi/tf/_mm_ERPoutfile2LEG1file_

Creating step 1

Creating Java mapping com/sap/xi/tf/_mm_ERPoutfile2LEG2file_

Start executing mapping sequence with 2 steps.

Executing mapping step 0

Loaded class com.sap.xi.tf._mm_ERPoutfile2LEG1file_

Call method execute of the application Java mapping com.sap.xi.tf._mm_ERPoutfile2LEG1file_

Cannot produce target element /ns0:MT_LEGFILE1_OUT/DT_LEGFILE1. Check xml instance is valid for source xsd and target-field mapping fulfills requirements of target xsd

14:08:10 End of test

[Former Member · Accepted solution]

Hi, Shuan:

Your interface mapping does not match your message mapping.

When you design your interface mapping, you put one source interface and two target interfaces, this is

multi-mapping scenario. However you do not have corresponding multi-mapping program. You just have two separate message mapping programs, this is the

reason causing the error.

If your IDOC need to be separted into two type of messages for your two target system,you need to design multi-mapppng

in your message mapping design, in source message type, select your source message type, in target message area, add your two types of messages.

Then going back to your design tab to continue on your designing.

Regards.

Liang

[Former Member · Accepted solution]

Liang,

Thanks for the direction I think this is going to help. One more point though. I'm not sure if it will allow me to do this (or maybe I'm just doing it wrong). When I go over to the message tab on the message mapping I want to identify my 2 target message types. Problem is my 2 message types exist in 2 seperate SWCV's. Everytime I enter 1 of the message types for a particular SWCV and then click the to add the second message type I have to change the SWCV. When I do that it removes the previously entered message type.

Is there a trick to capturing both under this scenario?

[Former Member · Accepted solution]

Hi, Shaun:

I think you should be able to do it, as I can not remember this details.

If you really can not do it, you can define SWCV dependencies in SLD, this allow the objects created in one SWCV visiable to another one.

Regards.

Liang

[ravi_raman2]

Shaun,

Your error has no bearing on software components.

Do a mapping test with the source and target messages......your xml source is not able to produce your target element.

Check if your target field "blahblahyadayada" is mandatory or not//!

Regards

Ravi Raman

[Former Member]

Shaun:

Your problem is not SWCV approach related problem, you should check you mapping program, do you use Message Mapping? it looks like the problem happens on your mapping design.

If you post more detailed information, people might propose.

Regards.

Liang

[Former Member]

I read your entire process and i feel that it should not create a problem

I am not clear what you want to acheive with your idoc data

as there are two receiver determinations interface determinations and agreements

where you are facing the problem

its easier to maintain the systems if you follow 3 SWCV approach

error you may be getting is regarding mapping error and check the occurence of targt message type

Rajesh

[turmoll]

Shuan,

I believe that 3 SWCV strategy refers to

- Interface SWCVs where you store interfaces, message types, data types, etc.

- Application SWCVs where you store message mappings and interface mappings, etc

So in your case you should have two interface SWCVs:

- SWCV_ERP_1 with IDoc matadata

- SWCV_Legacy with interface to legacy system

and one applicatio SWCV with mappings etc:

- SWCV_XI_1

be flexible

Glance these blogs:

- [Structuring Integration Repository Content - Part 1: Software Component Versions|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3607] [original link is broken] [original link is broken] [original link is broken];

- [Structuring Integration Repository Content - Part 2: Software Component Versions Revisited|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12417] [original link is broken] [original link is broken] [original link is broken];

and this doc:

- [SAP Exchange Infrastructure 3.0 Best Practises for Naming conventions|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90b213c2-d311-2a10-89bf-956dbb63aa7f]

Regards,

Jakub