SAP - EDI translator
Dave Darnell
I do not have any first hand experience with SAP but do know TSI is working
with the SAP software firm now on, what I have been told, a OEM version of
Mercator that will seamlessly do what you are describing.
I have enough experience with Mercator to know that it would probably be
able to handle this quite well. Once you had the Mercator Type Trees setup
for SAP you could use the resulting Type Tree structure to interface inbound
and outbound EDI (X12 and EDIFACT are already setup in Mercator Type Trees -
Odette I do not know about).
Mercator Map engines run on most platforms which makes it (from what I hear)
a good client/server match to SAP.
I would love to learn more about SAP, it seems to be the integrated
application business system software of choice. I heard that Motorola has
just committed a huge effort to converting legacy systems to SAP. Any
suggestions on where I can learn more about SAP?
At 07:11 PM 11/22/95 CET, Paul Matthe wrote:
> Hi,
>
> I am looking for a EDI translator that can directly handle SAP IDOC's
> and transform them into EDIFACT, Odette and X12 without the need for
> pre- or postprocessing programs to overcome the structure differences
> between these message standards and the SAP IDOC's. Any tampering with
> the SAP IDOC should be avoided. The translator software should
> seemlessly integrate with SAP (produce the control records, keep track
> of Idoc nrs and so forth) and be capable of handling a HUGE throughput
> of mixed standard documents. The possibility exists that one EDI
> gateway would be used for several SAP sites.
> Ease of developing and maintaining mappings is crucial (visual -
> drag&drop mapping) and there should be a proven track record of
> integration to SAP.
>
> I'd like to hear of the experiences out there with any translators
> that would be up to this. I have heard about something that sounds
> like 'OMNITRANS RMS' has anyone been working with it? How would TSI's
> Mercator do the job, any experiences there together with SAP? Is
> there anyone that could compare these two in fuctionality, stability
> and ease of use? Are there other possibilities?
>
> Thanks!
>
> Paul Matthe
> Cimad Consultants
> pm...@cimad.be
>
>
=================================
| David Darnell |
| SysTrends, Inc. |
| Arizona EC/EDI Roundtable |
| 1850 East Carver Road |
| Tempe, AZ 85284 |
| Tel (602)838-5316 |
| Fax (602)897-8479 |
| dav...@systrends.com |
=================================
Paul Matthe
Andy Coote
> > I am looking for a EDI translator that can directly handle SAP
> IDOC's and transform them into EDIFACT, Odette and X12 without the
> need for pre- or postprocessing programs to overcome the structure
> differences between these message standards and the SAP IDOC's. Any
> tampering with the SAP IDOC should be avoided. The translator
> software should seemlessly integrate with SAP (produce the control
> records, keep track of Idoc nrs and so forth) and be capable of
> handling a HUGE throughput of mixed standard documents. The
> possibility exists that one EDI gateway would be used for several
> SAP sites. Ease of developing and maintaining mappings is crucial
> (visual - drag&drop mapping) and there should be a proven track
> record of integration to SAP.
Perwill*EDI is fully approved by SAP and connects using IDOCS. High
throughput possible using automated processes. Current users include
Guinness Worldwide Brewing and Lego UK. All message standards are
supported and a wide range of them already interface with SAP. Supported
in UK, Europe, N America, Australia and Far East.
"Advertisers message"
Mail me for info rather than clog up the list with advertising!
Andy Coote
Wick Hill Business Communications
Woking Surrey UK
Eleanor G. Pickron
>
> I am looking for a EDI translator that can directly handle SAP IDOC's
> and transform them into EDIFACT, Odette and X12
This is the most a translator should reasonably be expected to do, and there
are several client-server translators that can meet this requirement.
> without the need for
> pre- or postprocessing programs to overcome the structure differences
> between these message standards and the SAP IDOC's.
The IDoc is not a 'message standard' at all; rather, it is a flat file
layout. There are an infinite number of configurations that an IDoc can
take. Someone sitting at an SAP system can create IDocs at will for
interfaces for EDI, for data movement between SAP systems, or for movement
between SAP and legacy systems. Therefore, no translator should be expected
to 'handle' specific data structures, within IDocs.
> Any tampering with the SAP IDOC should be avoided.
This is true; the IDoc will not work in SAP if it is violated. Therefore,
user exits from the translator must be built to handle situations as needed
for the specific situation.
> The translator software should
> seemlessly integrate with SAP (produce the control records,
There are seven translators that have been 'certified' to work with SAP, and
it can be obtained from SAP America in Philadelphia, or SAP AG in Walldorf,
Germany.
> keep track
> of Idoc nrs and so forth)
SAP has its own IDoc database that keeps track of the IDocs. They are only
application interface files.
> and be capable of handling a HUGE throughput
> of mixed standard documents. The possibility exists that one EDI
> gateway would be used for several SAP sites.
This is a pipe dream at this time; nothing meets this requirement, including
SAP itself. Client/server is still unstable technology, with the PC side as
its hardware achilles heel. Why ask more of the translator than the
hardware/operating system can provide?
> Ease of developing and maintaining mappings is crucial (visual -
> drag&drop mapping) and there should be a proven track record of
> integration to SAP.
SAP R/3, the client-server version, has not been around long enough to have a
proven track record itself. The IDoc first appeared in version 2.1, and has
now been made fully functional in version 3.0. No one has had an opportunity
to work with this file type for even six months yet in a production
environment, not even SAP, so there is no 'track record' available.
> I'd like to hear of the experiences out there with any translators
> that would be up to this.
Most of the functions listed are not translator responsibilities; it seems
that additional conversion software, interface add-ons for the Unix
environment will be required in the translator environment to provide support
to the SAP application interface. Please don't demand more of the
translator--it seems as if you think the translator isn't working properly if
it doesn't take on these additional tasks--tasks that have nothing to do with
translation into/out of accepted EDI standards.
As far as SAP education is concerned, Plaut and Origin offer SAP training in
Boston and Dallas. A five-week overview costs about $50,000, but individual
classes of lesser duration can be had via SAP itself. Documentation and some
detailed information can be obtained via SAP's web page. There are often
interesting attachments.
Eleanor G. Pickron
SAP IDoc. I work with SAP full time; (it's been a year now). Some of what
you've mentioned is possible, some of it certainly not within what can be
reasonably expected of any translator.
A new level of sophistication in design, called 'middleware' is needed to
interface successfully with SAP. It will take a good translator, some
additional table conversion software packages, voice response software, bar
code software, and enough 'C' programming to tie it all together to
adequately support a full-scale SAP implementation.
Mark Wonsil
Eleanor Pickron makes some excellent points and I would like to add a few
myself.
>In a message dated 95-11-22 13:30:40 EST, you write:
>>
>> I am looking for a EDI translator that can directly handle SAP IDOC's
>> and transform them into EDIFACT, Odette and X12
>
>This is the most a translator should reasonably be expected to do, and there
>are several client-server translators that can meet this requirement.
>
>> without the need for
>> pre- or postprocessing programs to overcome the structure differences
>> between these message standards and the SAP IDOC's.
>
>The IDoc is not a 'message standard' at all; rather, it is a flat file
>layout. There are an infinite number of configurations that an IDoc can
>take. Someone sitting at an SAP system can create IDocs at will for
>interfaces for EDI, for data movement between SAP systems, or for movement
>between SAP and legacy systems. Therefore, no translator should be expected
>to 'handle' specific data structures, within IDocs.
>
>> Any tampering with the SAP IDOC should be avoided.
>
>This is true; the IDoc will not work in SAP if it is violated. Therefore,
>user exits from the translator must be built to handle situations as needed
>for the specific situation.
>
In version 2.x, some users modified and even wrote their own IDOC's. This
was not a trivial task indeed. On version 3.x of R/3, SAP has made it much
easier to "extend" the IDOC's for user defined purposes.
>> The translator software should
>> seemlessly integrate with SAP (produce the control records,
>
>There are seven translators that have been 'certified' to work with SAP, and
>it can be obtained from SAP America in Philadelphia, or SAP AG in Walldorf,
>Germany.
>
Ah yes, "certification". It has yet to be seen if certification means that
it performs some minimal functionality or one just pays a registration fee.
As far as I've read, mapping is not a part of the certification process.
What R/3 does require is that the translator pass back the status of the
IDOC after several milestones of EDI processing. For example, R/3 wants to
know if and when the document was translated, sent and acknowledged. If the
translator cannot perform this, it escapes me how it can be classified as
"certified".
>> keep track
>> of Idoc nrs and so forth)
>
<snip>
>> Ease of developing and maintaining mappings is crucial (visual -
>> drag&drop mapping) and there should be a proven track record of
>> integration to SAP.
>
>SAP R/3, the client-server version, has not been around long enough to have a
>proven track record itself. The IDoc first appeared in version 2.1, and has
>now been made fully functional in version 3.0. No one has had an opportunity
>to work with this file type for even six months yet in a production
>environment, not even SAP, so there is no 'track record' available.
>
That is very true. I don't think you can even get a 3.0 demo at the North
American Demo center. (At least, not on their local machines.)
>> I'd like to hear of the experiences out there with any translators
>> that would be up to this.
>
>Most of the functions listed are not translator responsibilities; it seems
>that additional conversion software, interface add-ons for the Unix
>environment will be required in the translator environment to provide support
>to the SAP application interface. Please don't demand more of the
>translator--it seems as if you think the translator isn't working properly if
>it doesn't take on these additional tasks--tasks that have nothing to do with
>translation into/out of accepted EDI standards.
>
In our experience (with version 2.x and now starting our first 3.x), we
found this is very true. Maybe if all trading partners across all
industries use the transaction sets exactly the same, you can have your
wish. Until then, I would recommend you focus on the day-to-day business
solutions of EDI integration. In time, you will find this process much more
"crucial" than the occasional mapping exercise.
Mark Wonsil, CPIM
won...@trinary.com
Integration Systems Analyst
(810) 442-8540 Ext. 123
Eric A Christenson
Eleanor's experience with SAP rings true.
The ability to integrate with the SAP IDOC structure and feedback
mechanisms requires some sophistocation. The Unix based translation
software from St. Paul Software was the first North American translator
certified by the SAP organization in Waldorf Germany. The interface that
we provide comes with a GUI drag and drop mapping tool, all of the
required feedback mechanisms and a set of map templates for all of the R/3
rev 2.2 IDOCs. We are in the process of developing the same level of maps
and completing the certification process for the coming R/3 rev 3. For
more information you may contact me or our sales organization at
in...@spedi.com.
Eric A. Christenson
St. Paul Software
1450 Energy Park Drive
St. Paul, MN, 55108
On Thu, 23 Nov 1995, Eleanor G. Pickron wrote:
> In a message dated 95-11-22 13:30:40 EST, you write:
>
> >
> > I am looking for a EDI translator that can directly handle SAP IDOC's
> > and transform them into EDIFACT, Odette and X12
>
> This is the most a translator should reasonably be expected to do, and there
> are several client-server translators that can meet this requirement.
>
> > without the need for
> > pre- or postprocessing programs to overcome the structure differences
> > between these message standards and the SAP IDOC's.
>
> The IDoc is not a 'message standard' at all; rather, it is a flat file
> layout. There are an infinite number of configurations that an IDoc can
> take. Someone sitting at an SAP system can create IDocs at will for
> interfaces for EDI, for data movement between SAP systems, or for movement
> between SAP and legacy systems. Therefore, no translator should be expected
> to 'handle' specific data structures, within IDocs.
>
> > Any tampering with the SAP IDOC should be avoided.
>
> This is true; the IDoc will not work in SAP if it is violated. Therefore,
> user exits from the translator must be built to handle situations as needed
> for the specific situation.
>
> > The translator software should
> > seemlessly integrate with SAP (produce the control records,
>
> There are seven translators that have been 'certified' to work with SAP, and
> it can be obtained from SAP America in Philadelphia, or SAP AG in Walldorf,
> Germany.
>
> > keep track
> > of Idoc nrs and so forth)
>
> SAP has its own IDoc database that keeps track of the IDocs. They are only
> application interface files.
>
> > and be capable of handling a HUGE throughput
> > of mixed standard documents. The possibility exists that one EDI
> > gateway would be used for several SAP sites.
>
> This is a pipe dream at this time; nothing meets this requirement, including
> SAP itself. Client/server is still unstable technology, with the PC side as
> its hardware achilles heel. Why ask more of the translator than the
> hardware/operating system can provide?
>
> > Ease of developing and maintaining mappings is crucial (visual -
> > drag&drop mapping) and there should be a proven track record of
> > integration to SAP.
>
> SAP R/3, the client-server version, has not been around long enough to have a
> proven track record itself. The IDoc first appeared in version 2.1, and has
> now been made fully functional in version 3.0. No one has had an opportunity
> to work with this file type for even six months yet in a production
> environment, not even SAP, so there is no 'track record' available.
>
> > I'd like to hear of the experiences out there with any translators
> > that would be up to this.
>
> Most of the functions listed are not translator responsibilities; it seems
> that additional conversion software, interface add-ons for the Unix
> environment will be required in the translator environment to provide support
> to the SAP application interface. Please don't demand more of the
> translator--it seems as if you think the translator isn't working properly if
> it doesn't take on these additional tasks--tasks that have nothing to do with
> translation into/out of accepted EDI standards.
>