PI 7.11: Mapping inside or outside PI??

[Former Member]

Hi,

We have an IDoc to SOAP scenario.

Currently we have many issues with that interface, because the message mapping is very complicated (various entries per infotype have to be mapped to one target field etc.).

Wouldn't it be easier (especially for me as an ABAPer) to do the mapping in a user exit on SAP ERP side and call the PI WS from there?

Then we would have only to bypass the data through PI, because the inbound/outbound message type would be the same.

For me it always takes ages to find out what's wrong inside the mapping.

And the graphical mapping becomes very confusing even for easy mappings.

In ABAP the mapping part would be much easier!

What is here the best practice?

Do PI developers have always the aim to do all the mapping inside PI?

Thanks in advance!

[Former Member · Accepted solution]

Hi Eddie,

I see your question rather as an interface design question. In my experience it is best to follow this guideline:

- If you build interfaces SAP to SAP, go for IDocs, since you don't need to write a mapping and all extraction and posting logic is already defined

- If you build interfaces SAP to non-SAP, don't go for IDocs, use ABAP proxy. This allows you to "do the mapping in ABAP" as you said and will usually save you a lot of effort, just as you assumed. It is a lot easier to find some standard BAPIs or FMs in SAP that provide you the right objects and add some 1-to-1-assignments in the ABAP code than trying to squeeze all IDoc information into a completely different custom format.

All this "business login in SAP, structural logic in PI" is correct, but that rather refers to the specific problem, not to the interface design as a whole. Make you own experience, but in my integration scenarios I'll never agree on IDocs when the target format is custom.

Good luck!

Jörg

[Former Member · Accepted solution]

Thanks Joerg for your very helpful answer!

Unfortunately it seems that all our interfaces are crap, because we're using IDocs everywhere (also for interfaces to non-SAP systems)...

And they nearly all use BPMs which is in my opinion really a pain.

I will now change the interface to a synchronous SOAP-to-SOAP scenario.

Our newer interfaces are also designed that way and we have never issues with them.

And on ABAP side I can use the debugger to manipulate data before calling the WS.

I only see advantages to do it that way.

But there's one question popping up when using SOAP-to-SOAP:

Do we really need to have PI in that case?

The only reason I see: It's good to have a central point for all interfaces, but honestly that's the only advantage I see.

[Former Member · Accepted solution]

Hi Eddie,

I'm happy that I could help you.

To your question whether you need PI at all in SOAP-to-SOAP case:

This question you'll hear many times in many variants. ECC people may say, if you do a file interface, why can't we produce that file in ECC directly and put it into the target folder? My standard reply for this kind of question is: And who does the monitoring? Usually that silences people. In PI you have a very standardized way of monitoring, you can monitor all interfaces on one screen, and you can go deeper and define auto-reaction methods, alert emails etc. Same for your SOAP-to-SOAP interface.

I ask the same question when they suggest synchronous interfaces. If you're going synchronous the application needs to do all the monitoring and restarting logic. Easier to have it asynchronous and use the available standard. Now, that may be too generic, since there may be business processes that require a synchronous call, but I try to avoid them as much as possible.

Hope that gives you some new inspiration,

Jörg

[prateek]

>>What is here the best practice?

Let me tell you the best practice. There are two types of logic while sending data to partners 1. Integration Logic 2. Business logic. Integration logic is something which at times is customer specific, could be related to routing, value mapping, or some operation on data. e.g. field a and b should be concatenated before sending to receiver. This concatenation is integration logic. Business logic is something which functionally affects the flow. It is similar to any business requirement. Now Technically, both these logics can be implemented both in PI and ECC. But recommendation is, implement business logic in ECC and integration logic in PI. So try to follow this rule as much as possible.

>>In ABAP the mapping part would be much easier!

That's a developer choice. Java developer thinks it easier in Java

>>Do PI developers have always the aim to do all the mapping inside PI?

Well that depends how correct the PI developer is consulting.

Regards,

Prateek Raj Srivastava

[Shabarish_Nair]

But recommendation is, implement business logic in ECC and integration logic in PI. So try to follow this rule as much as possible.

>>>

Prateek has put it very well in the above sentence and i agree with this thought process.

It is always ideal to have the business logic abstracted from the middleware (not to be confused with a business process)

So if it makes sense that the validations can be done within the source system and that in the future managing it is much easier there, you should look to redesign the interface.

[Former Member]

Thanks guys!

Coming back to my example:

I have various elements for Infotype 0001 and one target field position (the one with ENDDA '99991231'.

Would you do that mapping inside of PI?

I did it now the following way:

[http://www.abload.de/image.php?img=mappingpxp88.jpg|http://www.abload.de/image.php?img=mappingpxp88.jpg]

Is that correct?

[baskar_gopalakrishnan2]

>Would you do that mapping inside of PI?

Yes this is perfect example for doing in PI. You logic seems to be right.

[prateek]

>>I have various elements for Infotype 0001 and one target field position (the one with ENDDA '99991231'

You can do this in PI.

But before doing it, analyze the entire requirement. You may also segregate the requirements into the two logics as I mentioned earlier and then implement some of it in ECC and some in PI. Other criteria of segregation should be level of complexity and availability of resources for implementation. If you are open for using both options, you can achieve faster and efficient implementation.

Regards,

Prateek Raj Srivastava

[Former Member]

Thanks so far!

Now I have another question

I've extended the IDoc HRMD_A06 with a segment that contains some target fields to be mapped in PI (e. g. EmployeeStatus ).

I did this, because we have to check several Infotypes to determine the correct EmployeeStatus.

Those fields are not linked to any HR Infotype, they're used in the target system only.

My idea is to populate those non-HR fields in user exit EXIT_SAPLRHA0_001 before sending to PI.

Then I have to do only a simple mapping inside of PI.

Is that a good approach in your opinion?

Or is it a problem to "misuse" the IDoc by adding fields not linked to any Infotype?

Thanks in advance!

[prateek]

>>My idea is to populate those non-HR fields in user exit EXIT_SAPLRHA0_001 before sending to PI.

Do you have any other option? If you extend an Idoc, then best practice is to populate it at ECC side only with user exits.

>> Or is it a problem to "misuse" the IDoc by adding fields not linked to any Infotype?

A good design would be, either don't extend HR idocs with non-HR field and handle it in some other way. Having said that, it is also necessary to analyze the efforts required for alternative solution. If it is too much and non-reusable , then you should go ahead with idoc extension.

Regards,

Prateek Raj Srivastava

[Former Member]

Hi,

my problem is still not solved

I've extended Idoc HRMD_A06 now.

The problem is, that it works only if i put the Z segment under segment E1PITYP, which is always linked to an Infotype (currently I put '0000' as Infotype).

E1PITYP contains the following fields:

PLVAR	PLVAR
OTYPE	OTYPE
OBJID	HROBJID
INFTY	INFOTYP
SUBTY	SUBTYP
BEGDA	PD_BEGDA
ENDDA	PD_ENDDA
LONG_INFTY	LONG_INFTY

I tried to put my segment under header segment E1PLOGI, but then SM58 gives me the following error:

Segment 'ZHRMD_A06', segmentnumber '000084' not correct in structure

E1PLOGI has the following fields:

PLVAR	PLVAR
OTYPE	OTYPE
OBJID	HROBJID
PROOF	CHAR1
OPERA	HROPERA
SERIAL_COUNTER	CHCOU
FILTER1	HRMD_FILTER1
FILTER2	HRMD_FILTER2

I don't really understand why I cannot do it that way...

My question:

Is there a way to include my data without linking it to an HR Infotype???

[baskar_gopalakrishnan2]

>In ABAP the mapping part would be much easier! What is here the best practice? Do PI developers have always the aim to do all the mapping inside PI?

Since you use PI enhancement version and will be in the latest version like 7.3, I would recommend to do only inside PI. I would not recommend doing abap mapping. Plus if you go for single stack java version, You would need to do only message,xslt or java mapping. So best practice to do only those mappings not abap mapping.

[Former Member]

Hi Baskar,

thanks for your reply.

I'm not intending to use ABAP mapping inside PI, but doing the ABAP mapping inside the source ERP system BEFORE calling PI.

This would let us change the scenario to a SOAP to SOAP scenario, where the inbound and outbound message type would be the same...

Therefore we would have a very simple mapping inside PI.

What is the advantage of doing the mapping on PI side?

For me it just makes everything more complicated.

Thanks in advance!

[Former Member]

Hi,

How are you planning to transform IDOC to SOAP inside ECC??

Am not sure, how easy & relevant it is.

I have a small suggestion to make things easier.

1)Go for RFC lookup inside PI mapping.

-: I am assuming your idoc is HRMD_A07 or some HCM idoc.

2)Send begda, endda,infotype no & subtype no as input parameters.

3)call that RFC from ECC & write the ABAP logic in ECC RFC.

4)write the generic code in the RFC .

Task can be accomplished only with work.

But, this will not be good from performance persepective.

Once, your complete mapping is over, ask someone on this forum to write a UDF for your RFC-ABAP code.

Then, re-place UDF in place of RFC lookup.

This idea is bit tedious, but, helps a lot to you, as you come from abap background.

[baskar_gopalakrishnan2]

>What is the advantage of doing the mapping on PI side?

For me it just makes everything more complicated.

Since you want to have slim validations/mapping efforts on the PI level, you could handle most of your validations at the backend logic. Nothing wrong on this. PI provides standard functions that can be used with simple tweak in the mapping area without coding. If you want to achieve the same in the backend you have to write logic entirely plus you do more maintanence coding on the application level. That is the advantage of using PI mapping. You can go with your convenience.

[Former Member]

Hi Santosh,

we're using the HRMD_A06 IDoc send via PFAL transaction.

Correct me if I'm wrong, but isn't it a mess to map various Infotype records to one target field?

E.g. we have to check in InfoType 0041 (Date Specifications) if an employee is still active or not.

In ABAP I would do a generic loop at all dates, but in the graphical mappings you have to check one by one (for Infotype 0041 we have 12 possible date fields!).

This leads to graphical mappings of an enourmous size and not everything can be solved through UDFs.

If I change something in the mapping it takes a long time before you can repeat a test scenario...

Thanks to Java! I also get heap space errors from time to time.

For me as a developer it's much more performant to work on the AS ABAP.

Can you recommend any tutorials/blogs/books/courses which explains the examples/best practive for doing an IDoc mapping in PI?

Thanks in advance!

[Former Member]

Hi,

That's correct. Everything cannot be done in one generic mapping.

But, the major portion of picking the records which lie in validity date can be done.

ANyways, you decided to do in graphical mapping. that's a better way for sure.

few useful links,

[http://wiki.sdn.sap.com/wiki/display/XI/PI7.0and7.1Mapping-Blogs,Articles,Wiki,CodeSamplesandVideos+Collections]

I haven't seen any better link than this.

[http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/46759682-0401-0010-1791-bd1972bc0b8a?QuickLink=index&overridelayout=true]

[http://www.saptotal.com/XIPIUDFSimple.html]

Coming to Heap space error,

Go for a complete cache refresh in RWB-->Administrator.

-santosh.