Why ALE?...........................................................................................................................

2
The SAP Solution - ALE.............................................................................................2
How it works?......................................................................................................................3
The Detail as descried y SAP...................................................................................!
"utound #rocessin$...................................................................................................%
&ecei'er deter(ination................................................................................................%
Data selection...............................................................................................................%
Se$(ent )ilterin$..........................................................................................................%
*ield con'ersion...........................................................................................................%
+ersion chan$e.............................................................................................................%
,nound #rocessin$......................................................................................................-
Se$(ent )ilterin$..........................................................................................................-
*ield con'ersion...........................................................................................................-
Data trans)er to the a##lication....................................................................................-
,n#ut control.................................................................................................................-
SAP &-3 ALE i(#le(entation (ethodolo$y.......................................................................
Phase /0 The Assess(ent and Pro1ect strate$y #hase...................................................
Phase 20 The Desi$n #hase...........................................................................................
Phase 30 The 2on)i$uration #hase...............................................................................3
Phase !0 The De'elo#(ent #hase................................................................................3
Phase %0 The "#erations #hase....................................................................................3
Phase /.............................................................................................................................4
Deli'erales durin$ this sta$e..................................................................................../5
Phase 2.........................................................................................................................../5
"ther considerations..................................................................................................//
Deli'erales durin$ this sta$e....................................................................................//
Phase 3.........................................................................................................................../2
Additional considerations........................................................................................../3
Deli'erales durin$ this sta$e..................................................................................../!
Phase !.........................................................................................................................../!
Deli'erales durin$ this sta$e..................................................................................../-
Phase %.........................................................................................................................../-
"ther considerations................................................................................................../.
Deli'erales durin$ this sta$e..................................................................................../3
ALE 2on'erter.................................................................................................................../3
ALE 6essa$e Handlin$...................................................................................................../4
Why ALE?
ALE is a business solution to a 'ery real need e(er$in$ in the SAP (arket. This is the
need )or usinesses to (o'e towards tighter integration etween syste(s7 yet7 at the
sa(e ti(e7 #ro'ide independence to the 'arious usiness units within the co(#any.
,n the #ast the (o'e was towards centrali8ed syste(s...
Standardi8ation o) usiness #rocesses acco(#anied y e'er ti$hter inte$ration within the
central syste( no lon$er re#resents a #racticale a##roach to this #role(. The )ollowin$
are so(e o) the (ost co((only encountered di))iculties0
technical bottlenecks,
upgrade problems,
the effect of time zones on international corporations,
excessively long response times in large centralized systems.
How do you achie'e this 9loosely coupled applications9 without co(#ro(isin$ data
inte$rity7 without co((ittin$ yoursel) to a s#eci)ic technolo$y7 without addin$ to the
technical issues (entioned ao'e.
What i) you want to link in to external systems as sea(lessly as #ossile?
The SAP Solution - ALE
SAP has #ro'ided ALE :A##lication Link Enalin$; as the solution to these issues. ,t
allows you to0
distribute your applications across several SAP systems, such that centralized
functions, as well as decentralized functions can operate in the same
company arena
maintain and distribute master data elements from a central system, thus
maintaining unique number ranges across several systems
maintain and distribute control data obects from a central system, thus
synchronizing important configuration data. !his is important when trying to
decentralise functions, yet keep them integrated
couple "#$ and "#% systems, in some instances
couple SAP and external systems, via &'ocs (&ntermediate documents) and an
external translation mechanism
ALE also #ro'ides you with tools that allow you to0
manage the A*+ process seamlessly. !hese tools include the reprocessing of
communication errors, business process and technical error handling and
routing via workflow, archiving of data
keep audit trails of all the A*+ communication
configure the A*+ solution in many different ways in order to tailor make a
solution for the user
,n SAP<s words0
"The ALE (Application Link Enabling) concept available in R/3 Release 3.0 supports the construction and
operation o distributed applications. !t incorporates the controlled e"change o business data #essages
$hilst ensuring data consistenc% across loosel% coupled &A' applications. The integration o various
applications is achieved b% using s%nchronous and as%nchronous co##unication( rather than b% #eans o
a central database.
ALE co#prises three la%ers)
the applications services,
the distribution services,
the communications services.
!n order both to #eet the re*uire#ents o toda%+s custo#ers and to be open or uture develop#ents( ALE
#ust #eet the ollo$ing challenges)
Communication between different software releases.
Continued data exchange after a release upgrade without special
maintenance.
Independence of the technical format of a message from its contents.
Extensions that can be made easily, even by customers.
Applications that are decoupled from the communication.
Communications interfaces that allow connections to third-party applications.
Support for !"-!# scenarios.
How it works?
ALE allows the user to #er)or( an SAP transaction in the sendin$ syste(7 a)ter which the
)ollowin$ ste#s occur0
, or more communication &'ocs (intermediate documents- container for the
application data) are created in the sending system database. An A*+
distribution model, that needs to have been configured, determines which
systems the &'ocs are to be sent
!hese communication &'ocs, that contain the relevant application data of the
transaction that was performed, are then passed to the A*+ communication
layer
!his layer performs an "./ call using the port definition and "./ destination
determined through the customer model
!he &'ocs are then transferred to the respective receiving systems. !hese
could be SAP "#%, "#$ or external systems
&f the receiving system is an SAP system then-
o &n the case of master data distribution the same transaction that was
performed on the sending system is again performed on the receiving
system with the data contained in the &'oc. !his allows the data to go
through the SAP checks before posting occurs
o &n the case of transaction scenarios the relevant data is passed to the
respective transactions in order to load the required application
document. +.g.. A P0 is loaded on the sending side, yet a S0 is
created on the receiving system
1aster data has another difference-
o &t can be set up in such a way that any changes made to specific fields
in master data tables can automatically trigger off the A*+ distribution
process for that particular master data obect
o &f a master data obect is created or changed on a sending system and
distributed to another system the respective transaction is used to
either create or change that respective master data obect on the
receiving system
,n $eneral7 i) standard SAP can<t #er)or( the task re=uired then neither can ALE. ,t
doesn<t add )unctionality7 it (erely decou#les it and allows you to distriute it onto other
re(ote syste(s.
The Detail as described by SAP
,n the out#ut #rocessin$ one o) the )unction (odules o) the a##lication creates an ,Doc7
the so-called (aster ,Doc. This ,Doc is sent to the ALE layer where the )ollowin$
#rocessin$ ste#s are a##lied0
Outbound processin
!ecei"er deter#ination
An ,Doc is si(ilar to a nor(al letter in that it has a sender and a recei'er. ,) the recei'er
has not een e>#licitly identi)ied y the a##lication7 then the ALE layer uses the
custo(er distriution (odel to hel# deter(ine the recei'ers )or the (essa$e.
The ALE layer can )ind out )ro( the (odel whether any distriuted syste(s should
recei'e the (essa$e and7 i) so7 then how (any. The result (ay e that one7 se'eral or no
recei'ers at all are )ound.
*or each o) the distriuted syste(s that ha'e een ascertained to e recei'er syste(s7 the
data that is s#eci)ied y the )ilter o1ects in the custo(er distriution (odel is selected
)ro( the (aster ,Doc. This data is then used to )ill an ,Doc7 and the a##ro#riate syste( is
entered as recei'er.
Data selection
Se#ent $ilterin
,ndi'idual se$(ents can e deleted )ro( the ,Doc e)ore dis#atch y selectin$ *unctions
)or the ,Doc #rocessin$ -? Settin$s )or )ilterin$ in ALE 2usto(i8in$. The a##ro#riate
settin$ de#ends on the sendin$ and recei'in$ lo$ical &@3 Syste(.
%ield con"ersion
&ecei'er-s#eci)ic )ield con'ersions are de)ined under *unctions )or the ,Doc #rocessin$
-? 2on'ersions.
Aeneral rules can e s#eci)ied )or )ield con'ersionsB these are i(#ortant )or con'ertin$
data )ields to e>chan$e in)or(ation etween &@2 and &@3 Syste(s. *or e>a(#le7 the )ield
9#lant9 can e con'erted )ro( a 2-character )ield to a !-character )ield.
The con'ersion is done usin$ $eneral E,S con'ersion tools :E>ecuti'e ,n)or(ation
Syste(;.
&ersion chane
SAP ensures that ALE )unctions etween di))erent &@3 Syste( releases. Cy chan$in$ the
,Doc )or(at you can con'ert (essa$e ty#es o) di))erent &@3 releases. SAP De'elo#(ent
use the )ollowin$ rules when con'ertin$ e>istin$ (essa$e ty#es0
.ields may be appended to a segment type2
Segments can be added2
ALE 2usto(i8in$ kee#s a record o) which 'ersion o) each (essa$e ty#e is in use )or
each recei'er. The correct 'ersion o) the co((unication ,Doc is created in the ALE
out#ut.
The resultin$ ,Docs :it is #ossile that se'eral ,Docs could e created in the recei'er
deter(ination; are re)erred to as co((unication ,Docs and are stored in the dataase.
The dis#atch control then decides which o) these ,Docs should e sent i((ediately.
These are #assed to the co((unications layer and are sent either usin$ the transactional
&e(ote *unction 2all :&*2; or 'ia )ile inter)aces :e.$. )or ED,;.
,) an error occurs in the ALE layer7 the ,Doc containin$ the error is stored and a
work)low is created. The ALE ad(inistrator can use this work)low to #rocess the error.
'nbound processin
A)ter an ,Doc has een success)ully trans(itted to another syste(7 inound #rocessin$ is
carried out in the recei'er syste(7 in'ol'in$ the )ollowin$ ste#s in the ALE layer0
Se#ent $ilterin
Se$(ent )ilterin$ )unctions the sa(e way in inound #rocessin$ as in outound
#rocessin$.
%ield con"ersion
S#eci)ic )ield con'ersions are de)ined in ALE 2usto(i8in$.
The con'ersion itsel) is #er)or(ed usin$ $eneral con'ersion tools )ro( the E,S area
:E>ecuti'e ,n)or(ation Syste(;.
Aenerali8ed rules can e de)ined. The ALE i(#le(entation $uide descries how the
con'ersion rules can e s#eci)ied.
"ne set o) rules is created )or each ,Doc se$(ent and rules are de)ined )or each se$(ent
)ield.
The rules )or con'ertin$ data )ields )ro( an &@2-s#eci)ic )or(at to an &@3 )or(at can e
de)ined in this way. An e>a(#le o) this &@2 - &@3 con'ersion is the con'ersion o) the
#lant )ield )ro( a 2 character )ield to a ! character )ield.
Data trans$er to the application
'nput control
When the ,Docs ha'e een written to the dataase7 they can e i(#orted y the recei'er
a##lication.
,Docs can e #assed to the a##lication either i((ediately on arri'al or can )ollow in
atch.
Dou can #ost an inound ,Doc in three ways0
,. by calling a function module directly- A function is called that imports the
&'oc directly. An error workflow will be started only if an error occurs.
$. by starting a SAP 3usiness 4orkflow. A workflow is the sequence of steps to
post an &'oc.
%. by starting a work item A single step performs the &'oc posting.
The standard inound #rocessin$ settin$ is that ALE calls a )unction (odule directly. *or
in)or(ation aout SAP Cusiness Work)low alternati'es re)er to the online hel# )or ALE
#ro$ra((in$.
SAP !-( ALE i#ple#entation #ethodoloy
There are asically % #hases o) the #ro1ect that need to e co(#leted se=uentially0
Phase )* The Assess#ent and Pro+ect stratey phase
Look at the business needs, map these to ALE, determine gap and implications, prototype if
necessary, agree and sign-off scope
Phase ,* The Desin phase
Naming standards, distribution settings, future flexibility, audit requirements and technical impact,
DR and archi!ing strategies
Phase (* The -on$iuration phase
"onfirm business requirements, basis config, functional config, #A and testing and sign-off
Phase .* The De"elop#ent phase
$unctional specifications, technical specifications, de!elop and configure, #A and testing and
sign-off
Phase /* The Operations phase
Define support roles, capacity planning, %ob monitoring, failure reco!ery and problem resolution
Phase 1
" Before commencing with an ALE implementation, certain tasks need to be
undertaken, certain delierables produced and final decisions made!!! "ithout the
support of senior pro#ect management ALE implementation will not succeed!!!"
A small, full$time, team :/-2 #eo#le; needs to e (oili8ed with the )ollowin$ skills0
!echnical background2
'etailed A*+ knowledge2 and
5igh level functional understanding.
Workin$ to$ether with this tea( should e a )ew applicable, part$time functional
experts.
This tea( needs to assess the usiness needs to see i) ALE is the (ost )easile solution
)or the usiness. They need to conduct the )ollowin$ tasks e)ore co((encin$ with ALE
desi$n0
/. $usiness re%uirements assessment 6 1ap out what the business needs, both
present and future, ito-
o 'istributable functions2
o /ommon master data2
o !echnical- 7p6time, response time2 and
o Audit 8 legal requirements.
2. A&E investigation
o "esearch applicable A*+ scenarios2 and
o &f need be, /onfigure and 'emo prototype.
3. A&E gap analysis
o 1ap business requirements to standard A*+ functionality2 and
o 'ocument gaps and highlight implications.
!. Confirm business ! A&E scope
o 0btain sign off for the agreed scope of the A*+ implementation
proect.
Deli"erables durin this stae
ALE Whitepaper 6 3usiness requirements assessment, A*+ functionality
mapping, impact assessment (functional and technical). 9ap analysis.
ALE Team Approach 6 "esource 8 skill requirements, deliverables and
deadlines.
Sign-off of scope 6 !he agreed scope of the A*+ &mplementation proect
must be signed6off.
Phase %
" &nce it has been decided, by management, to pursue the ALE option we need to
design a potential ALE solution!!!"
To do this7 the ALE tea( needs to #er)or( the )ollowin$ ste#s in the de'elo#(ent
en'iron(ent0
/. 'evelop standards ( procedures early)
o :aming standards- *ogical systems, reduced message types, custom
obect types, custom function modules2 and
o /hange management procedures- 'etermine how you are going to
manage the various clients and their different configurations. 'efine a
process for configuration changes.
2. 'ocument the various settings, per scenario, that are required to implement
the solution. !hese include-
o 1essage types and fields2
o .ilter obects2
o Serialization2
o Push ;s Pull2
o &mmediate ;s background processing2
o /onversion rules2
o /entrally managed on which system<2 and
o ...
3. *uture flexibility must be catered for in the design. !his is especially
important when considering the organization structure as certain scenarios
require certain control data to be in synch across the various clients. !his is
difficult to change once implemented...
!. Audit re%uirements for transaction scenarios must be noted and designed for.
/onsider archiving, audit message types.
=. /onsider the potential technical impact of the proposed A*+ solution ito disk 8
processor utilization, network usage, dialog 8 background processing.
Archiving strategy as well as disaster recovery planning
-. Sign-off the design together with the business.
Other considerations
A*+ migration to production strategy and timing.
Deli"erables durin this stae
ALE 'aming (tandards - Set the standards )or all con)i$uration.
ALE )esign )ocument - Details usiness #rocess7 )unctional i(#act7 technical i(#act
oundaries7 work)low re=uire(ents7 ti(in$ o) 1os7 ...
ALE *hange +anagement Procedure - Sche(atic dia$ra( o) u# to date client
con)i$uration status7 con)i$uration chan$e re=uest #rocedure7 ALE con)i$uration check
sheet.
ALE *onfiguration (ign$&ff Procedure - A$ree on the #rocess to )ollow durin$ EA
and Production #hases o) the #ro1ect. Durin$ #roduction7 transactions cannot e #osted to
test the correctness o) the solution...
ALE +igration (trategy $ How are you $oin$ to #ut the 'arious clients into #roduction7
ti(in$7 i(#lications on usiness #rocesses.
Phase ,
"-emember to configure &'L. what is signed off by the business in the confirm
business requirements stage!"
The )ollowin$ ste#s need to e noted when con)i$urin$ your ALE solution0
/. Confirm business re%uirements 6 3efore commencing configuration ensure
that you have the detail of the business requirements for the whole scope of
the implementation.
2. /onfigure the A&E basis portion to enable A*+ in the development
environment. !his involves the following steps-
o /reate *ogical System (*S) for each applicable A*+6enabled client2
o *ink client to *ogical System on the respective servers2
o /reate background user, to be used by A*+, on each client2
o /reate "./ destination for each destination client2 and
o 9enerate partner profiles for sending system. (/an only do this if at
least , message type exists against the sending system>s *S). !his
automatically generates the port if the *S and "./ name are the
same.
3. .ollowing the basis configuration is the functional configuration-
o /reate a /ustomer 'istribution 1odel (/'1)2
o Add appropriate message types and filters to the /'12
o 9enerate outbound partner profiles2
o 'istribute the /'1 to the receiving systems2 and
o 9enerate inbound partner profiles on each of the clients.
Fee# your ALE con)i$uration dia$ra( u# to date and )ollow chan$e (ana$e(ent
#rocedures ri$orously7 as you e$in to conigure. Areas you need to docu(ent well
include the )iner details in'ol'ed with an ALE i(#le(entation0
o *istings # classes2
o 0bect types ? 4orkflow tasks2
o /onversion rules2
o .ilters 8 Segment filters2
o /hange pointers ? .ields activating change pointers2
o Serialization2
o Partner profiles- &mmediate ;s 3ackground2
o 3ackground ob definition and scheduling2
o /ontrol data required to be in synch2 and
o ...
%. +A ( testing) 'emonstrate ? workshop this solution with the business.
'ocument and draw up functional specifications (done by the business) of any
extensions to existing scenarios or additional scenarios required.
%. Sign-off each client configuration with the business owners.
Additional considerations
Ge'er do client co#ies. ,) necessary7 re(e(er to redo the con)i$uration #ertainin$ to
lo$ical syste(s as these will e out o) synch. Also re(e(er to archi'e irrele'ant ,Docs7
re(o'e useless chan$e #ointers and useless custo(er distriution (odels.
Deli"erables durin this stae
ALE *onfiguration Procedure - Details ho$ to #er)or( the con)i$uration.
ALE )etailed *onfiguration /uide - Details $hat the actual 'alues are )or each o) the
ALE-con)i$urale areas are )or your #articular solution.
ALE Basis *onfiguration Procedure - Details how to #er)or( the asis con)i$uration
)or ALE. Hsed y the Casis tea(.
ALE "orkflow *onfiguration Procedure - Details how to con)i$ure the work)low
error (essa$e handlin$ )or ALE.
Phase 0
"1o do ALE deelopment your scenario designer will need in$depth knowledge of
2)ocs, ALE scenario deelopment and ALE configuration! A handy knowledge of
ABAP is also re3uired!!!"
/. *unctional specifications need to be drawn up, by the business, describing
exactly what is required by them, that is not available in the standard A*+
scenarios.
2. A technical specification can then be drawn up by the A*+ team. &n this
technical specifications the following needs to be addressed-
o :ew &'ocs required2
o :ew fields added to existing &'ocs2
o Program ? user exits ? message control for populating the fields2
o &nbound functional module details2
o A*+ configuration set up requirements2 and
o +rror handling.
"nce the s#eci)ication is co(#leted and con)ir(ed y the usiness7 #ro$ra((in$ can
e$in.
3. 'eveloping an A&E scenario will include the following steps)
OUTBOUND:
o /reate Segments and &'oc type2
o /reate 1essage !ype and link to &'oc type2
o Populate &'oc using message control ? user exit or program (A3AP)2
o 'istribute &'oc using 1AS!+"@&'0/@'&S!"&37!+2
o /reate obect type if required2
o 'efine /'1 with message type and filter obect. 'istribute model.
9enerate outbound partner profiles2
2'B&4')5
o 4rite inbound function module (.1) to process inbound &'oc (A3AP)2
o /reate process code and link to .12
o 9enerate inbound partner profiles2 and
o *ink obect type to .1 for error handling.
!. +A ( ,esting 6 &ncluding unit and string testing. +nsure a quality solution. AA
done by the A*+ team leader and testing done by the business owner and A*+
scenario developer.
%. Sign-off by the business 6 +nsure the development is thoroughly tested and
comprehensively documented prior to sign6off against the functional
specification.
Deli"erables durin this stae
ALE Functional Specification 6 .or each development a detailed functional
requirement document is produced and confirmed by the business.
A*+ Scenario 'evelopment 9uide 6 'etails what development was done and
how to configure the solution. :eeds to be AA>d by someone else in the know.
Test Procedures 6 7nit and string testing needs to be conducted on the
development together with result logging and sign6off.
Phase 6
" 1he operations support area needs to be well skilled in order to handle the
support re3uirements when going lie! 1he initial period during go lie may be
intense, re3uiring twice or three times the amount of normal support! 1his intense
support re3uirement will dwindle a couple of months after go lie!!!"
+arious areas7 #ertainin$ to the "#erations I Production en'iron(ent need to e
addressed CE*"&E you $o li'e0
/. A&E Administrator role defined and sourced. "esponsible for A*+ configuration
and issue resolution.
2. Capacity plan including A&E I'oc archiving strategy 6 /onsider the growth of
the A*+ solution, procedurize the archiving of &'ocs while considering the
legal implications.
3. A&E -perations role defined and sourced. "esponsible for A*+ archiving,
background ob scheduling and monitoring.
!. A&E failure recovery procedure 6 4hen a soft failure occurs (&.+. 4hen a
system is restored to a previous point in time) a recovery procedure needs to
be implemented... 5ow<
=. 'efine the A&E support organi.ation structure. !he A*+ administrator will
receive the A*+ problems when in production. 7sing a troubleshooting guide
the problems can be resolved.
Other considerations
:ever do client copies... &f you do, check on-
o the change pointer table (3'/P?S)2
o the &'oc table (+'&'/?S)2
o all the logical system references, and
/lient specific configuration-
o &mmediate processing on the outbound and inbound side should be
avoided due to the fact that A*+ takes every available dialog process,
on the receiving system, when performing the send.
o /onfiguration needs to happen, on6line, in production systems for
versions up to ;B
+rror handling- 4orkflow is used to trap error messages. &f you have 1S
+xchange then consider implementing the integration between 1S and SAP as
this will help the A*+ administrator with , in6box of errors as apposed to , per
client that he supports
A*+ specific scenarios
o !he classification master and it>s respective master data obect
(vendor, material or customer) are not linked, in any way, via A*+
message types up to ;B. !his implies that the classification master
may end up on systems where it is irrelevant
o 0SS notes need to be implemented to improve the speed of the
programs "3'APPC,, "3'1A:&:, "3'1&'0/, "3'S!A!+
Deli"erables durin this stae
ALE Administrator Troubleshooting Procedure 6 4hat to do when the
unexpected happens...
ALE Archiving strategy and procedure 6 4hen and how are you going to
archive the &'ocs. "emember the legal implications.
ALE Capacity Planning uide 6 /heck the growth and plan for expansion.
ALE Failure and recovery procedure 6 &n case a system needs to be
restored to a point back in time, how do you recover<<<
ALE Production client cleanup procedure 6 4hen a client is created, what
steps do you need to take to clean it up< 4hen a system is brought down
what do you need to check<
ALE -on"erter
The ALE conce#t in'ol'es usin$ e>ternal con'erters to connect non-SAP syste(s to the
&@3 Syste(. E>ternal con'erters are $eneric )or(at con'ersion #ro$ra(s. The )ollowin$
con'erter )unctions are co'ered y SAP 2A-ALE certi)ication JALE 2on'erters?
They ha'e the )ollowin$ #ro#erties0
the transfer of "#% intermediate document (&'oc) formats straight into their
own repository so that these data descriptions can be used as source or
target structures when assigning data fields.
adoption and conversion of intermediate documents from "#% Systems via the
A*+ interface 6 a remote function call that can be called up using a normal
transaction.
conversion of any data format into intermediate document structures and
import into the "#% System via a remote function call ("./) in the A*+
interface.
ALE con'erters enhance the conce#t o) ED, susyste( inter)aces y0
using direct program6to6program communication instead of a file interface to
transfer &'ocs
recognizing the format of any interface structure of a non6SAP system and not
ust standard +'&.A/! or A:S&6D,$ formats.
ALE 0essae Handlin
An ALE Message Handler acts as a bridge between SAP R/3 and another application or multiple
other applications. It receies intermediate documents !I"ocs# $rom one or more instances o$
SAP R/3 and carries them to application!s# $or processing. Li%ewise& it sends I"ocs receied $rom
applications to one or more SAP R/3 instances.
In contrast to an ALE conerter& the message handler will not do an' conersion or mapping but
instead delier I"ocs without changing them. It is assumed that a message handler has some
sort o$ (ueuing mechanism and guarantees reliable delier'.
)he $ollowing SAP *SP members hae certi$ied products handling messaging+
,EA S'stems -,EA eLin% $or R/3.
*ompa( *omputer -*ompa( ,usiness,us.
Hitachi -Message /ueue 0Access.
I,M !12# -M/Series $or R/3.
2aba ,en3ing -,0*4MM $or R/3 ERP.
5E45 5ew Era o$ 5etwor%s -5E45adapter.
)I,*4 So$tware -)I,/AciteEnterprise.
)SI International -Mercator.
6iewlocit' -AM)ri7 S'stem.