Figaf
SAP PI Architecture
Guidelines
Figaf
CONTENTS
Preface .......................................................................................................................................................... 4
Software Component Naming Conventions .................................................................................................. 5
Business and solution maps ...................................................................................................................... 5
Three component architecture................................................................................................................... 6
Product Naming ......................................................................................................................................... 7
Software component versions naming ...................................................................................................... 8
Using industry solutions ............................................................................................................................. 9
Third party content ................................................................................................................................... 10
Namespaces ............................................................................................................................................... 12
HTTP or URN .......................................................................................................................................... 12
Placement of software component name ................................................................................................ 12
Abbreviations ........................................................................................................................................... 12
PI component namespaces ..................................................................................................................... 12
Folders ..................................................................................................................................................... 13
Scenarios .................................................................................................................................................... 14
Naming of the scenarios .......................................................................................................................... 14
Actions ..................................................................................................................................................... 14
Views ....................................................................................................................................................... 15
More resources ........................................................................................................................................ 15
B2B .......................................................................................................................................................... 16
Configuration ........................................................................................................................................... 16
Enterprise Service Repository objects ........................................................................................................ 17
Interface objects ...................................................................................................................................... 17
Service Interface .................................................................................................................................. 17
Figaf
2
Service operation ................................................................................................................................. 18
Messages types ................................................................................................................................... 19
Datatypes ............................................................................................................................................. 19
External Datatypes ............................................................................................................................... 20
Transformation ........................................................................................................................................ 20
Operation Mappings............................................................................................................................. 20
Message mapping................................................................................................................................ 21
Imported archives ................................................................................................................................ 21
Configuration ............................................................................................................................................... 22
Technical systems ................................................................................................................................... 23
Business Systems ................................................................................................................................... 23
Business Component .............................................................................................................................. 24
Integration Process Service..................................................................................................................... 25
Parties...................................................................................................................................................... 25
Communication channel .......................................................................................................................... 26
Folders ..................................................................................................................................................... 26
Figaf
3
PREFACE
Based from the principle of SAP’s PI Best Practices Naming Conventions, this
article is be very helpful and should be used whenever possible. It differs from SAP’s
guideline on naming object due to the need to create clarity. This guide provide a
more concrete examples on describing infrastructure in using the applied solution
maps.
Figaf
4
SOFTWARE COMPONENT N AMING CONVENTIONS
This guide provides an easy to implement structure in naming conventions of how
you organize software components and namespaces. Names of the software
conventions are quite important on how everything should be organized in PI
repository. The Business and solution maps in this organization is provided by SAP.
It is much easier to make sure that Business processes are covered by using maps
to organize business.
BUSINESS AND SOLUTION MAPS
SAP ERP is the most used business model since it contains best practiced and
standard ERP procedures. Solution maps is the way SAP has organized their
content into different silos.
Figure 1 ERP solution map
Main processes which are splits into business process contains different services as
provided by SAP. The rows indicates the different process categories that is a silo of
the organization. Retail industry is one of the most common specific solution maps
industry.
Figure 2 Retail solution map
Shown in the image below is the process that corresponds to a business scenario.
Cross industry solution maps grouping are different from one another.
Figaf
5
Figure 3 Retail scenario groups
Business scenarios are results of splitting group scenario. Business process is from the split business
scenarios like cross industry solution maps which shows a lot of similarities. To show the difference
between the two layers refer to the graph below.
Level
Cross industry Solution
Industry solution maps
maps
1
Solution Map
Solution Map
2
Process categories
Scenario groups
3
Main processes
Business scenarios
4
Business process
Business process
Table 1 Levels of a solution map
This table reflects translation between Cross industry and solution maps. Selecting
the right solution map that suits most of your solutions is essential. Using the ERP to
all non core business such as HCM and analytics while using the processes in your
industry solution map is possible.
THREE COMPONENT ARCHITECTURE
SAP has indorsed the three component architecture for components. This
architecture works by having some interface components where all the information
used on the remote systems are located. In the SAP PI component everything
regarding process is stored it is mappings, BPMs and scenarios.
Figaf
6
Interface A
SAP PI
Interface B
Figure 4 The 3 way split of components into interface and an application component
There are exceptions where BPM and mapping are placed to interfere with
components. Example, you can use three systems having identical interfaces but
one system with a small change to the interface. In this case, BPM and mappings in
the interface component which produces an output of the interface component
similar to an enterprise service.
PRODUCT NAMING
A part mentioned in the SAP guidelines for products and software components is
that they should contain company name.
Naming convention is

I_<SOFTWAREPRODCUCT>

A_<SOFTWAREPRODCUCT>
A is for applications where all PI logic is placed and I is for interface components.
The following is examples of the structure
Figaf

·I_SAPERP

·A_SAPPI

·I_MDM

·I_EXCHANGE

·I_SALESFORCE

·I_SEEBURGER
7
SOFTWARE COMPONENT VERSIONS NAMING
The software component versions (SWSV) are brief name used in namespace which
should be as short as possible. The PI 7.1 can handle namespaces longer than PI
7.0, however making it difficult in maintaining and finding correct namespace. Each
product should create software components. The three components can be created
following SWCV which could not be relevant, but make all components for MDM that
only uses HCM.
Process Category
Abbreviation
PI SWCV
SAPERP SWCV
MDM SWCV
Human Capital Management
HCM
A_SAPPI_HCM
I_SAPERP_HCM
I_MDM_HCM
Financials
FIN
A_SAPPI_FIN
I_SAPERP_FIN
I_MDM_FIN
Product Development & Collaboration
PDC
A_SAPPI_PDC
I_SAPERP_PDC
I_MDM_PDC
Procurement
PRO
A_SAPPI_PRO
I_SAPERP_PRO
I_MDM_PRO
Sales and Customer Service
SCS
A_SAPPI_SCS
I_SAPERP_SCS
I_MDM_SCS
Manufacturing
MAN
A_SAPPI_MAN
I_SAPERP_MAN
I_MDM_MAN
Enterprise Asset Management
EAM
A_SAPPI_
I_SAPERP_ EAM
I_MDM_EAM
EAM
Cross Functions
CRO
A_SAPPI_ CRO
I_SAPERP_ CRO
I_MDM_CRO
Shared Service Delivery*
SSD
A_SAPPI_SSD
I_SAPERP_SSD
I_MDM_SSD
Table 2 Examples of software component versions
The example is not a process category in the ERP map but it does make sense to
look at it as a process category. Components within the same group should be
dependent of the basis products wherein you can use the shared functions of the
Business PI component in all the A_PI components. In the same manner that some
standard interfaces for SAP ERP system can be found in the B_SAPERP. Example,
the ALEAUD or a data type can be used as multiply scenarios. The canonical
definition component is suggested in defining (Global) data types, which should then
be imported by the SWVC using this datatype.
For EDI partners, like the Seeburger EDI components like I_SEEBURGER_PLE and
I_SEEBURGER_SAS can be created. There should only be created the componets
to be used. Then the SLD/ESR is not filled with too many version to create
confusion.
Remember to add the B_SEEBURGER to make sure you have a place to store the
Figaf
8
global data types and other components shared for the processes.
USING STANDARD CONTENT
A large part of what SAP is working on is creating the Enterprise Service Bundles that contains
different functionality. The use of those components is really important. Therefore the components
need to be used in a way that allows reuse of SAP components.
With PI 7.11 it is possible to add the dependency with using Underlying dependency from the
Enterprise Service Builder(Repository). It is though recommended to create the dependencies in the
SLD and create installation time dependency there. It will give a better overview of what is going on
and what is connected.
USING INDUSTRY SOLUTIONS
In some instances it makes sense to use the industry solutions. If you are
implementing a scenario closer to you’re the solution maps, then it may be an idea to
implement that solution. It will give a better resolution of the process.
For the retail solution map the view could be something like this.
Scenario
Abbreviation PI SWCV
SAPERP SWCV
MDM SWCV
groups
Merchandise
MER
A_SAPPI_MER A_SAPERP_MER A_MDM_MER
SCM
A_SAPPI_SCM A_SAPERP_SCM A_MDM_SCM
SMC
A_SAPPI_SMC A_SAPERP_SMC A_MDM_SMC
EMS
A_SAPPI_EMS A_SAPERP_EMS A_MDM_EMS
Lifecycle
Supply Chain
Management
Store & Multi
Channel
Enterprise
Management
& Support
Table 3 Software component versions when using industry solutions
The same rules apply for these components as for the normal solution map.
Figaf
9
THIRD PARTY CONTENT
Third party content can be used in PI installations. The possibility of having an ISV
(Independent Software Vendor) can create an integration which you want to use is
not disregarded. They can have made a full integration with scenarios mapping APIs
for their content. If it produces a complete package of integration then – you can
select to use their components and have it configured, or move the object into
components matching the solution.
Easy access for support and upgrade makes the off-the-shelf package provide edge
however; it could lead into one messy system which is not suited for your own
integration. Migrating the content from your SWCV is easier to understand
architecture, however support from the vendor will be difficult and that you will need
to make sure the content is working now. Selecting from the options will depend on
the complexity of the package – if the vendor delivered more mappings or BPMs
then don’t consider the migration.
If they have delivered a set of interfaces, you can import the software component.
You can create a dependency from the I_SEEBURGER_SAS to the component
delivered by Seeburger. It is then possible to create your own Service Interfaces,
which links to the components delivered by Seeburger. This proves the
Enhancement package delivered by SAP by using the naming convention where all
objects are place in namespace. Therefore, you can create actions for configuring
your scenarios.
DEPENDENCIES
The following model can be used to add software components and be able to use
the SAP delivered content.
Integration Scenarios
B_SAPPI
Common ERP component,
Mapping, BPMs etc
B_SAPERP
Interface objects
I_SAPERP_S
CS
ESM Standard hierarchy, common
objects for 3.td party systems
ESM_INTEGR
ATION
ERP and BI standard components
ESM_ERP
I_SAPERP_H
CM
A_SAPPI_SCS
I_OIOUBL_SC
S
I_MDM_SCS
C_SAPPI
C_OIOUBL
ESM_BI
EA_APPL
FINBASIS
Figaf
10
Notice that you need to have included all the standard components and the chain
that they are using, to use the structure delivered by SAP.
Figaf
11
NAMESPACES
Using namespace helps in getting a structure which is easy to maintain and to be
sure that everything is placed in proper locations. Good structures leads to locating
the objects much easier when change is needed.
HTTP OR URN
SAP PI best practice includes the URI naming convention. However the software
components in SAP, the HTTP convention are used. These two can be used with
minimal effects from one another. HTTP is widely used since it fits most with the
Enterprise Services included in SAP.
The big difference is when you developing java objects. Then a name space like
http://figaf.com/salesmngt is converted to a package called com.figaf.salesmngt.
Where the namespace in urn form urn:figaf-com:salesmngt will be converted to a
package called figaf-comsalesmngt. This has an impact when you are working with
Java proxies, but also when you are working with java functions in mappings or
functional libraries.
PLACEMENT OF SOFTWARE COMPONENT NAME
It would be difficult locating the correct namespace if the SWCV is not in the
namespace. But if the same namespace is used in multiply components it will be
difficult to pick the right place to select object from. It is essential to know when you
should use dependencies from other components. It is suggested that you put the
software component name in the end of the name to sort out the namespace and
find all the namespaces relating to the right section and then select the correct
component.
ABBREVIATIONS
The 60 characters of namespace in PI 7.0 and XI 3.0 was expanded in the PI 7.1 to
120 characters, however it is recommended to limit the namespace as short as
possible to avoid eating up a lot of screen spaces.
PI COMPONENT NAMESPACES
When the software components is organized using the solution maps the
namespace can also follow this. The solution maps are divided into two different 4
different levels. This can be used when defining namespaces.
Figaf
12
In Table 1 was showed the different levels of the solution map. Using this information
it is possible to compose the name spaces. The namespaces is created using the
following different layers.
http://[CompanyDomain]/[Main processes]/[Business Process]/[SWCV]
http://[CompanyDomain]/[Business scenarios]/[Business process]/[ SWCV]
Ie. http://figaf.com/SalesOrdMgnt/AccountProc/I_SAPERP_SAS.
Software components consisting of several integrations requires business process
which is always visible with SAP components but also with other third party
applications that has a lot of integration but using only one namespace. The PI
components in the business process should not be include because it often interacts
with multiply business process making it difficult to locate or place the components.
When the PI object span multiply main process or the SWCV the scenarios should
be placed in the main process together with the most focus.
The Excel spread sheets lists all the software components in SAP ERP solution
manager with some in abbreviated form for easier implantation. Just copy and paste
from the document to the namespaces. It would have been nice if it was possible to
distribute the namespaces when they are already created, but then the software
component was branded to figaf.com, and that will not make sense.
FOLDERS
Folders are new in PI 7.1 which allows you to better group objects. A problem with
using these folders is that it can limit the way reused is performed. Another way in
organizing the content better is to use one folder per scenario then placing all objects
from the object inside that component. The same way that you can use a folder to
group if it will be used again by a multiply scenarios in the software component.
The good thing about folders is that they are not tying the objects the same way as
namespaces are. If you move an object into a folder, then you can always move it
out fo the folder. It is not possible to move objects between namespaces.
Figaf
13
SCENARIOS
Using the scenarios properly will allow you to increase the development and
configuration. It takes some time to get use to using the scenarios. It would be easier
for other people to understand your development and that objects are configured
correctly. Using these scenarios can even make it possible to communicate the
business process.
NAMING OF THE SCENARIOS
All development should start with the naming of the scenarios, so the usage of them
is even important.
A revised format for then naming is the following
[<Application>_]<Business Process>

Application can be should mostly be the abstract name of the service like Portal service
instead of SharePoint. The reason is that you could drop your SharePoint server and then
the scenario should still work, when you insert a SAP Portal. You can also use the same
scenario with different views if you are using SharePoint and SAP side by side. The
application is optional; some scenarios are not tied to a solution.

Business Process should be the process the scenario is a part of. The scenario should be
more general than just Currency, ie. CurrencyUpdate, where there is a more focus on what
is being performed by the scenario.
ACTIONS
The actions are the place where all the objects are connected in the scenario.
According to the Guidelines Actions should be named
<Business Object><Opertation>
Figaf

·The Business Object is the object in question. It can be PurchaseOrder or Contract.

·Operations can be
o
Send
o
Receive
14
o
Create
o
Request
o
Change
o
Update
o
RequestUpdate
It is really curial to remember to create the descriptions, since they will be showed in
the scenario diagram. Making the scenario diagram is much more readable. In the
descriptions it also makes sense to have a naming convention. Some ideas can be

Provide (for services provided)

Consume (when a client consumes a service synchronous)

Request

Update

Delete
Using third party interfaces actions can be placed in the PI software components you
have created. This is for you to implement enhancement packs without overwriting
your actions, making it available for future use. The SWCV should depend on the
SAP enhancement component. Then the action can use the service interface objects
defined in the content delivered by SAP.
VIEW S
Views should be used if the different system all working in the same scenario has
different interfaces and integration. There should therefore be a view pr system if the
interface differs.
MORE RESOURCES
Daniel Graversen’s blog shows how to use scenarios. It contains information how
auto configuration works by attaching communication templates to your scenarios. –
here is the link http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10282
Figaf
15
B2B
Scenarios are different when using the B2B communications. It is possible that one
scenario can be used for the whole sales process while covering incoming orders,
order confirmation and providing notes and invoices. B2B is often dealing with
different version of documentation such as x12, EDIFACT and other version that
follows.
CONFIGURATION
The scenario name should be maintained in configuration for obvious reasons. If
multiply view is needed then each view can be configured using separate folders.
This will make it easier finding objects configure per scenario. When a scenario
needs to be reconfigured it make sense to delete all other objects for the scenario
and reconfigure everything making the exercise easier in the migration to production.
Figaf
16
ENTERPRISE SERVICE REPOSITORY OBJECTS
Aside from namespaces a large exercises creating the objects relating in the
Enterprise Builder Repository which are described chronologically. This guide does
not contain all the objects found in SAP, if an object is not found in this list refer to
the SAP guidelines.
INTERFACE OBJECTS
The interface objects are all objects that are defined to make sure data is created the
correct way.
SERVICE INTERFACE
The naming convention used in XI 3.0 uses the prefix with aa (async abstract) or so
(sync outbound) while with PI 7.1 the meaning is split into two different objects – the
Interface and Operation. These conventions cannot be maintained because the two
types are placed in separate objects. Using two different objects in the new
standards is necessary since the abbreviation a_ or o_ would be difficult understand
for non PI developers. Grouping operations into an interface should be related to one
another as is with the same business object.
XI 3.0 compatible services components should be named after the service interface.
So be at that naming convention.
SAP defines the service interface on the following way
<Business Object><Interaction Activity>_<Direction>

<Business Object> Specify the underlying business object representing business content

<Interaction Activity> What is done with the BO. It could be processing if it contains more
service operations, if it just contains one service operation then the activity must be more
specific to the operation like update, or copy

<Direction> Inb | Out | Abs should be the same as selected on the interface mapping
Example
Figaf
17

InvoiceProcessing_Out (if there are more service opertations)

InvoiceCreation_Out _Async(if it is a XI30 service opertation)

InvoiceRequestStatus_Inb
When there are multiply EDI documents for invoice they should be placed separate
service interfaces.

InvoiceX12_4010_Out

InvoiceX12_4060_Out
SERVICE OPERATION
Creation of complex integration is possible in PI 7.1 because of the new service
interface. Assigning names that matches the service is recommended for others
such as third party developers and business users understanding. Likewise it is
necessary for names to be brief as possible to comprehend the meaning. The name
for both service interface and service operation should be the same on the XI 3.0
compliant interfaces to reflect the difference between the two operations.
SAP defines the Service interface in the following way.
Syntax
For Interface Pattern stateless:
Operation Name
<Business Object><Action><Transaction Activity>?_<Mode>
For Interface Pattern stateless XI 3.0 compatible:
Operation Name
<Business Object><Action><Transaction
Activity>?_<Mode>_<Direction>
Glossary
<Business Object>
Specify the underlying business object representing business
content
<Action>
Create | Change | Update | Cancel | Maintain | Modify | Delete |
Read | <Other>
<Transaction Activity>
Request | Query | Notification | Confirmation | Response |
<other>
<Mode>
Sync | Async
<Direction>
Inb | Out | Abs
Figaf
18
The <BusinessObject><Action> should correspond to the service interface used for
the object.

SalesOrderUpdate_Inb

EmployeeRecordMaintainQuery_Inb
MESSAGES TYPES
The message type is used in describing the root node of the XML document.
Application design identifies the third party integration. Business users define the
elements since it is only guide lines. The message should refer to the business
object transferred and the operation is associated with the element.
SAP define the syntax the following way.
Syntax
Message Type Name
<Business Object><Action>?<Message Type Category>
Glossary
<Business Object>
Specify the underlying business object representing business content
<Action>
Create | Change | Update | Cancel | Maintain | Modify | Delete | Read |
<Other>
<Category>
Notification | Request | Confirmation | Query | Response | <Other>
Category should be the same as used in the service interface.
DATATYPES
The datatypes as received a large change in PI 7.1. Especially with the creation of
global datatypes that makes reuse much easier.
SAP defines datatypes the following way.
Syntax
Data Type Name
<Business Object>
Glossary
<Business Object>
Specify the underlying business object representing business content
SAP recommends that all development comply with CCTS or the Core Component
Technical Specification wherein all the base components in creating message type is
defined. This allows reusing the components.
The use of CCTS construction in enterprise datatypes makes it easier since all the
Figaf
19
field names are the same. If a datatype will not be used again as it is a used as
definition of a file interface there is no need to define all software components as
basis components. The need for a major modification of the backend system
prohibits in the creation of CCTS for IDOC and RFC structure thus mapping between
the CCTS and SAP is defined.
EXTERNAL DATATYPES
External objects should be named accordingly to the business object
described. SAP has defined it the following way.
Syntax
External Definition
<Business Object | Message Type>
Glossary
<Business Object>
Specify the underlying business object representing business content
<Message Type>
Use the message type as specified in the XSD for instance
TRANSFORMATION
The transformations objects are used to convert one XML document into another
document type.
OPERATION MAPPINGS
The mappings are defined during the operation mapping. Naming should be based
according to the service operation involved in the mapping. Always use all involved
service operations. Use ‘to’ indicator to describe where the source list starts and in
cases of multi mappings use the _multi naming convention.
SAP has defined the operations the following way
Syntax
Operation Mapping
<Source Service Interface>?<Source Service Operation> (_and_<Further
Source Service Interface>?<Further Source Service Operation>)*_to_<Target
Service Interface>?<Target Service Operation>(_and_<Further Target
Service Interface>?<Further Target Service Operation>)*(_multi)?
Glossary
<Service Interface>
Specify the service interface name omitting direction
<Service Operation>
Specify the service operation name omitting
Figaf
20
MESSAGE MAPPING
The message mappings should reflect the messages involved with the mapping.
This should include all the different documents involved.
This version is expanded from the SAP version
Syntax
Message Mapping
<Source Message Type>(_and_<Further Source Message Type>)*
_to_<Target Message Type>(_and_<Further Target Message
Type>)*(_multi)?(_<variant>)?
Glossary
<Message Type>
Specify the message type name
<Variant>
Often you can map the same messages but the content you want form the
message can be different. It can therefore be necessary to make
distinctions for each mapping. This should be done in the variant phase.
The variant is a new addition, which helps to identify the correct mapping when more
mappings map the same message but with different meanings. Variants can be
convert or change mode.
IMPORTED ARCHIVES
The use of imported archive requires the source code of java mappings for the
content, if not the code must exist in company version control systems like CVS,
subversion or MS Source Safe. It will not be possible for other users to fix bugs in
the maps if the code cannot be altered by other developers. The creation of
automatic build scripts will speed up the process for creating better packages and
reuse of the components used.
Syntax
For archives containing one single mapping only:
Archive Name
<Source Message Type>_to_<Target Message Type>_<Technology>
For archives containing several mappings:
Archive Name
<Application | Mapping Category>(_<Technology>)?
Glossary
<Message Type>
Specify the message type of the source and target message
<Technology>
XSL | Java
<Application>
Specify an application the archives are related to
<Mapping Category>
Use a group name to categorize your archives
Figaf
21
PROCESSES
The integration processes is used to control the flow internally in SAP PI.
INTEGRATION PROCESS
The integration process is used to define ccBPM processes to control the PI system. They can be
defined in the following way.
If the processes is used as a standard pattern it may be easy for people to understand what it does.
Syntax
Integration Process
<Business Object><General Action | Pattern>
Glossary
<Business Object>
Specify the underlying business object
<General Action >
Specify an action which is carried out by the integration
process, e.g., replicate,
<Pattern>
SyncAsyncBridge | Collect | Multicast | Serialize | <Other>
Figaf
22
CONFIGURATION
Configuring your system requires you to cover all aspect such as the SLD where
technical and business system is configured. Then there is the actual configuration
and creation of objects in the directory. These two components is connected which
makes it easier in understanding the connection with the business systems.
From a monitoring perspective, it is easier to see where the message is send
therefore the prefix BS_, BC_ and PRC_ is used in describing business system,
business components and business process.
In dealing with a system run by a partner you have to use a business component and
not a business system. This is the kind of system that you have no influence over.
Third party systems are system within your own system landscape.
TECHNICAL SYSTEMS
SAP described that there is a need for one technical system for each environment. It
is not necessary. It does not help that there are more technical systems it will just
make everything a bit more complex.
This of cause does not apply to SAP systems, because they are automatically
resisted with their system name.
The modified system looks like this.
Syntax
Technical System
<Location | Organizational Area>?<Business Application>
Glossary
<Location>
Specify the geographical area the system is located in
<Organizational Area>
Specify the business unit the system is assigned to
<Business Application>
Specify your actual business application or usage of the system
Using only one system will make the configuration much faster, because there is
only one system to maintain. There is still the option of creating multiply business
systems on this technical system.
BUSINESS SYSTEMS
The business systems are defined to have a distinction between the different PI
environments and make it possible to define transport paths between the different
Figaf
23
systems.
The adapted version of the business system looks like.
Syntax
SAP System
BS_<System ID><Client>_<Stage>
Other System
BS_<TechnicalSystem>_<Stage>
Glossary
<SystemID>
Specify the three digit number of your SAP system
<Client>
Specify the client number of your SAP system
<Stage>
D | Q | P | T | <Other>
<TechnicalSystem>
The technical system the business system is passed on.
When naming the SAP systems it can be redundant, to have information about which
stage the system is used on. Some time you may want to use the same SAP system
for both test and quality assurance, then you need the information. Also it may be
unclear what the naming strategy is for objects.
Other systems should have the same naming as the technical system, to make it
easier to find.

BS_CSP100_P

BS_PIP200_P

BS_Exhcange_P

BS_Halo_D
BUSINESS COMPONENT
The business components or business services as they was known as in XI 3.0, is
used when communicating with systems outside your IT landscape. The name of the
component should align with the service provided by the partner. The name can also
reflect to the business object in question like the sales order.
Syntax
In case of B2B:
Component Name
BC_<Service | Business Object><Role>?
Glossary
<Service>
Specify a business function or transaction
<Business Object>
Specify the underlying business object representing business content
Figaf
24
<Role>
Buyer | Seller | <Other>
Compared to SAPs recommendation is the technical adapter removed, and it is
recommend using business systems instead.

BC_Salesorder

BC_CurrencyRates
INTEGRATION PROCESS SERVICE
When a process is created as service in the integration directory it should use the
same name as in the repository. However if an integration process can be re-used
as a service for multiply system the process instance can be configured in each
system. This makes the monitoring much easier.
Syntax
Integration process service
PRC_<System>?<Integration process name>
Glossary
<System>
In some instances a process can be configured to work
with multiply systems. Then an abbreviation of the
process should be used
< Integration process name>
Name from the repository
PARTIES
Parties are used to communicate with any third party system and should be used in
dealing with a B2B scenario. In case of geographical grouping, groupings are done
in the front this allows the sales region in finding their partners within the same
territory. This makes the monitoring easier.
Syntax
For several partners of same
company in different locations:
Party Name
<Description of Partner><Location>?
For a large number of external partners:
Party Name
<Location>?<Description of Partner>
Glossary
<Description>
Figaf
Specify the name of your partner
25
<Location>

Figaf

CentralBank

FrancePartnerA

FranceBankOfFrance
Specify a geographical area. Country, domain or ISO 3166
codes
COMMUNICATION CHANNEL
The name of the communication channels should reflect the adapter type. The
channel does not need to reflect which business system it corresponds with,
necessary in the XI 3.0 when you need information of which service is used as a
channel.
SAP has defined the channel the following way.
Syntax
Channel Name
(Ack_)?<Adapter Type><Direction><Object |
Description>?
Glossary
<Adapter Type>
IDoc | RFC | File | JDBC | JMS | Proxy | SOAP | Http |
Mail | RNIF | <Other>
<Direction>
Sender | Receiver
<Object>
Specify an underlying business object or message type
<Description>
Describe the usage of the channel

FileSenderSalesOrder

SOAPReceiverUserinfo
FOLDERS
Configuring scenarios should be stored in a separate folder to make it easier to fine
and organize the content. New objects are tied with the folder when they are
reconfigured making the transport and reconfiguration much easier. The folders
should be created in a structure that corresponds to the location of the scenarios as
shown in the structure sample below.

Figaf
ANA
26
o
o

EndUserService

<SCENARIONAME>

<SCENARIONAME>
FinancialAna
 <SCENARIONAME>
SCS
o
SalesOrdMgnt
There are some objects there are used in more scenarios, and then objects must be
placed in the folder they both share.
Figaf
27