Inbound SUBMAS IDOC from external system

[Former Member]

All,

We are implementing an interface between SAP EHS and an external formulation system.  The interface using SUBMAS IDOCs is bi-directional, meaning that data will be sent from the formulation system to SAP EHS and data will be sent from EHS to the formulation system, however not the same data points.  We also have intention to use the REPMAS IDOC, one way, to update the report status in the formulation system. We are converting, on the outbound side, the IDOC to the required XML for the formulation system within the middleware, and will be doing the same on the inbound side, converting the XML from the formulation system, to a SUBMAS IDOC to be posted within SAP.

Now, the inbound processing is expected to both create and update specifications, or update existing specifications.  It is on the inbound processing that my questions focus.

1. Has anyone had any experience with processing inbound SUBMAS IDOCs created from an external non-SAP system?
   • How did it work for you?
2. Which inbound processing function module was used for SUBMAS?
   • We are currently looking at BAPI_IDOC_INPUTP and BAPI_IDOC_INPUT1, both of which seems to do the same no matter which flags we set in the IDOC
3. Does any documentation exist on what the settings should be within the SUBMAS IDOC to process in specific ways? For instance:
   • Overwrite existing data (identifier or value assignment instance)
   • Append/add value assignment instance regardless of existing data
4. Do you perchance know how to separate the generation of the REPMAS from the generation of the DOCMAS? We have considered:
   • Filtering all sections of the IDOC except the header and ESTDH section.
     

Thank you in advance for any help that you can offer.

[christoph_bergemann · Accepted solution]

Dear Willem

Let us assume this situation

External System <=> XI/PI <=> SAP ERP

In most cases the data flow is: SAP => XI/PI => External System

For the other direction the following informations are needed (but XI/PI is not needed; it is only a potential solution and the most common one)

1.) in external system any "customizing" / "phrase" etc.must be present; then via XI/PI you can generated clearly an IDOC (it is more than one IDOC) to be booked in SAP EHS

2.) As the "most" common approach is SAP ERP => SAP ERP it is clear that SAP must support these "subprocesses"

Data changed in source system in EHS. We have high level these action:

Insert

update

delete

All of that must ! be supported in ALE

Therefore:

1.) yes you can create a spec with ALE

2.) yes you can do update on spec with ALE

3.) yes can add data (second data record e.g in density) with ALE

The "tricky"! thing is the "operating" mode and the starting point. in SAP you always start from hit list; then ALE is triggered (for initial distribution !)

The other way around need to be arranged by you !

So it is not of "interest" if the source system is a SAP system or a Non SAP system; as long as the IDOC are generated correct it will work

IN context ot:

1. Which inbound processing function module was used for SUBMAS?
   • We are currently looking at BAPI_IDOC_INPUTP and BAPI_IDOC_INPUT1, both of which seems to do the same no matter which flags we set in the IDOC

I can not answer this; you need to address this with ALE experts

1. Does any documentation exist on what the settings should be within the SUBMAS IDOC to process in specific ways? For instance:
   • Overwrite existing data (identifier or value assignment instance)
   • Append/add value assignment instance regardless of existing data
4. There is no documentation: you can learn from the SAP => Non SAP system (or SAP = SAP) approach (how it works so to say)
5. 
   
6. 
   
7. Do you per chance know how to separate the generation of the REPMAS from the generation of the DOCMAS? We have considered:
   • Filtering all sections of the IDOC except the header and ESTDH section.

Quite tricky question never investigated; but in ALE you have filters (but e.g. user exits) but only for SUBMAS if i remember correct

So for "REPMAS" and "DOCMAS" In this special context  can not help

Good luck

C.B:

PS:

Please consider this: you have (If I understood you correct) an outbound part (e.g. a compositon is pushed to external system) and an inbound part; the "tricky" topic is the inbound topic. E.g. if an user "blocks" the spec (in CG02 Edit mode) you will not get an update

Honestly: if you have a big company and a huge user community and you run e.g. rule sets etc. there is nearly "only a  "second" time chance to do the "inbound" update"; as long as one ! user is in CG02 edit mode no update is possible for the effected spec! So this is the "tricky" thing. If you have a small company (acting only 8 h per day) then you have enough time so that SAP does have a chance to book the data within 24 h; but if you have a big company and there is a user in CG02 "always" and "block" the spec there is "less" chance to get the updaze (but it is possible from technical point of view)

[Mark-Pfister]

Hello Willem,

Willem Bonthuys wrote:


Has anyone had any experience with processing inbound SUBMAS IDOCs created from an external non-SAP system?

How did it work for you?

I have done a project for an international company in the flavor and fragrances area that used a very similar approach:

They did send a minimum set of data from their formulations system to the SAP EHS System via ALE.

This data was the composition and some physical safety data - just enough to run the rule sets on SAP EHS side (Flashpoint, state of matter etc.).
The system then automatically did run all the rules, generated the MSDS and placed it on a network share where a pull mechanism from the formulation system picked it up and imported it into the formulation system.

This is all over 10 years ago so I do not recall all the details!

It required quite a bit a reverse engineering to get the Inbound ALE right and figure out what data fields exactly we needed to populate. But I the end we were able to create a stable interface. If for some reason things go wrong you can re-process the IDOC over and over again - or if SAP is down you re-send it form IX. (And all of this automated if you wish)

So I think this is a good approach.

However I think we just created substances and did not update them. The sending of data to SAP EHS to generate the SDS was one of the last steps in their business process.

If they needed to change the formulation they would re-create a new specification in SAP EHS.

I think we did not send substance data at all back to the formulation system - the MSDS was enough and we do not send back the reports via ALE .

I think there is might be one issue with this sending reports per ALE:

You would need to distribute the final reports (SBEs) and not the raw reports (SBRs) .

Within SAP EHS you normally ALE the SBRs to my knowledge. So the ALE of the SBEs might not be well tested.... Furthermore most SAP EHS system are set up to only temporarily store the SBEs and delete them after two weeks.

Hope this helps

Mark

[christoph_bergemann]

Dear Mark

good points that you mentioned

1.) yes normally only "SBR" (or IBD) documents are distrbuted via ALE

2.) and yes normally SBE documents are only available may be 10days

I am not sure; but SBE can only (potentially) be dispatched via CVD1; I am really not sure if this is suported. BUt if SBE would be stored (and not deleted) the the "document" as such can be distributed (I assume via DOCMAS only); as no parameter data are left and the report is really "final" The "onyl" topic which i don't know. to "handle" reports (manage them) some "key data" would be helpful; e. material number (all this is stored in CVDHH etc.). I believe we can not distribute via ALE CVDDH etc.

So at the end: I believe ALE distributon of SBE documents is not support (but really not sure; never investigated)

generally i can confirm your "set up" (which data is sent/received etc.) to be a valid process (and we can prepare a corresponding SAP set up); but this kind of set uo is not used "often" in my opinion

Generally any "similar" design is possible as well. E.g. by using "Exits" in CG02 you can call an external system "Direct" communicate and get data back; this is more or less the design of SAP EHS and communication to  "EHS Expert Server"; but not using "ALE" as the "technology" to "link" SAP to a different system.

C.B:

[Mark-Pfister]

Hi Christoph,

Generally any "similar" design is possible as well. E.g. by using "Exits" in CG02 you can call an external system "Direct" communicate and get data back; this is more or less the design of SAP EHS and communication to  "EHS Expert Server"; but not using "ALE" as the "technology" to "link" SAP to a different system.

Sure there are a million and one ways to set up such a system landscape .

Which one is "the best" highly depends on the clients requirements:

- Should one still be able to work in one system even if the other is down

- Performance requirements

- Overall system landscape

- etc....

I would prefer to build such a system with only a "live / direct / synchron interface based on RFC calls of BADIS / APIs:

- The advantage is no synchronization issue

- The disadvantage is that if one system is down you can not work (fully?) in the other

Greetings

Mark