cancel
Showing results for 
Search instead for 
Did you mean: 

Import long text via Idoc SUBMAS02 into E1BP1077RI

former_member602203
Participant
0 Kudos

Hi together,

we would like to Import via Idoc Scenario (SUBMAS02) more than 132 digits to the IDENTIFIER in segment E1BP1077RI. How could I do this?

In manuel way, there is the longtext availible but I don't see this possibility in Idoc...

Accepted Solutions (1)

Accepted Solutions (1)

satya11719
Active Contributor
0 Kudos

Hello Holger,

Please try E1BP1077IL , and do let me know if it is useful for you.

Thanks

Satya

Answers (6)

Answers (6)

christoph_bergemann
Active Contributor

Dear Holger

as I have tried to explain: start with the other way around ..

Not being the ALE expert story is like: you need more than one "segment"; all of them (according to my understanding) are needed to handle per segment 132 CHARs. So if you have a "long text": you need as much as E1BP1077IL segments to pass on the data.

Always the best is to learn from: do an "outbound".. and based on what you can see. try the "inbound"

C.B:

christoph_bergemann
Active Contributor
0 Kudos

Dear Holger

I have done a further check via google and found this document:

http://www.amicuk.com/lsmw-bus1077-specifications-for-cg02/

Could be of interest to you

The same here: https://blogs.sap.com/2016/03/10/lsmw-for-specification-management/

So generally: LSMW approach can "trigger" the generation of SUBMAS IDOCs

In many cases ALE is partially outdated" and for data integration now "WebServices" are used more and more often

Keep in mind my comment: the "target object" (spec id) is not ! allowed to be edited by somebody. In this case the ALE inbound process can not work; this is a general issue which is as well true if somebody would like to use SAP EHS OCC for data import. The target objects should ! not be blocked by different user and honestly: in may be roughly 1% of cases this is the case; so somebody is blocking the spec id in "Edit" mode; so you need a strict control of ALE INbound process; the goods news is: the IDOC is still there; the bad news is: the inbound process (if spec id was blocked) must be started now manually

C.B.

PS keep in mind: the "customizing" content of the IDOC must be in sync with the target system

E.g. if in the IDOC a component type "X" is used but "X" does not exist in the target system: the inbound is not possible. The same is true for any "phrase" related information, "UOM" related information of information based on e.g."Regulatory lists"

To make an example: if you use content (like former CLEO) per "CLEO" update you will get a guidance document: what kind of "new customizing" must be established or which "new master data" (like phrases) must be established

I have no clue how you have arranged this correlation to your business case; but it can be a point point for the "Inbound" process

christoph_bergemann
Active Contributor
0 Kudos

Dear Holger

I have done a further check via google and found this document:

http://www.amicuk.com/lsmw-bus1077-specifications-for-cg02/

Could be of interest to you

C.B.

former_member602203
Participant
0 Kudos

Dear Christoph,

thanks, interesting even my question regarding long text is solved and import is used since years successfully.

christoph_bergemann
Active Contributor
0 Kudos

Dear Holger

based on your last comment this is now my picture:

a.) We have a Non SAP system as the source system; this system creates "XML" files

b.) You have still some "middleware" in place (but not SAP PI) to get an IDOC based on XML file

I am not the ALE expert. But may be get in touch with an "ABAPer" and check this function module:

C14ALE_IDOC_INPUT_SUBMAS

This function module "consumes" at the end SUBMAS IDOCs. On top: generally take a look on function group C14ALE; here all relevant function modules for ALE handling are managed

Overall: so the trick is (in my opinion) to look on the "middleware" which needs to transform the XML file to an SUBMAS IDOC (including long text options)

There is on tzhe top some "but" (kind of warning):

1.) if you create a new spec: this should be no problem

2.) but if you do updates on existing spec. The list of issues here is "endless"; e.g. the spec ID is not allowed to be "blocked" by a user or process in "Edit" mode

Even looking on SAP to SAP connection for SUBMAS: there is always a risk that in "inbound" process something can go wrong; so a "strict" monitoring is needed.

The issue might be: you might not always know at which point in time an "IDOC" need to be consumed; but the IDOC inbound handling (for SUBMAS) create a log (refer to SAP help). You can check this Log for "issues" and based on that you have a better chance to manage the ALE

Discussion in this FORUM has shown, that the SUBMAS handling is not easy and there a lot of pitfalls to consider.

But the monitoring of ALE and "error" fix is really time consuming and the error fixes handling is a different story

As shortly explained: yes we have some ALE discussion here, But quite limited (< 20 threads ?) and your scenario is specific (but refer to the othere listed threads; some of them refelct your wish a little bit

C.B.

christoph_bergemann
Active Contributor
0 Kudos

Dear Holger

now you have "lost" me..

Let us assume this scenario:

You have a target SAP ERP system in which EHS is prepared. The IDOC can only be "booked" in the system based on two approaches

1.) the spec id is still part of the IDOC

2.) or by using e.g. an "identfier" the corresponding target object can be identfied

1.) is the variant you should use (but how should teh soruce system know your spec ID ?). Now if you have a souce system in which EHS data is prepared we have two choices/options:

The source system is a SAP system or the source system is a "non SAP" system

For Case one. SAP can handle outbound and inbound without any problem (I am not aware o any problem). Here you need to influence teh SAP approahc. The "long text" are corrected dispatched and booked in the target system

For case 2: in most case you use SAP XI/PI as "middleware" and then this creates the IDOC for EHS

If you use this option: the SAP XI/PI must be prepared in such a way to generate the correct IDOC structure so that long texts are supported (I am not an ALE expert); but important is: in SAP XI/PI the "mapping" must be done so that the spec ID is identifed or you will not get the IDCO booked in the target system

May be this document might help a little bit:

https://wiki.scn.sap.com/wiki/display/HOME/Step+by+Step+procedure+for+creation+of+IDOC

For relevant "technique" part. https://wiki.scn.sap.com/wiki/display/ABAP/List+of+BAPI%27s

could be of interest and there: e.g. BAPI_BUS1077_SAVREPMUL

Here some threads which are linked "partially" to your topic:

These are related the "inbound" topic

https://answers.sap.com/questions/10741548/data-transfer-of-substances-fails.html

https://answers.sap.com/questions/12327599/inbound-submas-idoc-from-external-system.html

https://answers.sap.com/questions/107314/hello-willem-just-to-ask-how-you-have-used-the-inb.html

and this is related to "outbound" topic

https://answers.sap.com/questions/3491390/extraction-program-for-ehs-ehs-to-xi-scenario.html

https://answers.sap.com/questions/9087412/idoc-from-ehs-tables.html

https://answers.sap.com/questions/10687821/background-possibility-for-data-exchange-ale-with.html

https://answers.sap.com/questions/9823515/mapping-of-properties-to-characteristic-fields.html

C.B.

former_member602203
Participant
0 Kudos

Dear Christoph,

yes ist quite complicated and I have never heard from other EHS customers that approach / scenario which we use succesfully since 3 years.

Regarding your comment we use this:

1.) the spec id is still part of the IDOC -> data came out of an non SAP System via XML.file and we have used SAP PO in the past but now we have a Service Provider with his own midlleware which generate out of the xml, IDOC on our system which generate new specs or update These specs...

christoph_bergemann
Active Contributor
0 Kudos

Hello Holger

up to now i never get in touch with one person using ALE for data migration/data import

We can use some assumptions:

1.) any "long" text (like identfier or user defined text) can be distributed via ALE without any doubt

2:) But if your "segment" is the right one to look at? No idea

The "best" is (like with EHS standard import) first to do the "other way" around

So you have a spec with an identfier which is longer than 132 digits: distribute this spec to some target system. SAP EHS is doing the right "thing" in the right sequence. Then just check the IDOC structure and how in SAP standard the "outbound" is done. Based on that: you can do the "inbound" (hopefully)

A further option is: if you have a ABAPer : check the document here: https://www.consolut.com/en/s/sap-ides-access/d/s/p/5/doc/YY-EHS_MD_120_40_02.html

There is a standard BAPI which is doing the work

E.g. check:

There are some threads discussing "similar" challenge

https://answers.sap.com/questions/10066398/distribution-of-specifications-using-ale-with-reci.html

https://answers.sap.com/questions/7131264/ehs-interface-to-distribute-the-specification-data.html

https://answers.sap.com/questions/12327599/inbound-submas-idoc-from-external-system.html

https://answers.sap.com/questions/107314/hello-willem-just-to-ask-how-you-have-used-the-inb.html

https://answers.sap.com/questions/9087412/idoc-from-ehs-tables.html

C.B.

former_member602203
Participant
0 Kudos

Hi Christoph,

there is always a first time. 🙂

We use Idoc's szenario from service provider which send us all informartion about our substances (GHS, transport classification, first aid, waste codes, chem and physical infos and so on....)