CTS_with_SAP_BW

1

Using the Corrections and

Transport System(CTS) with SAP BW

2

SAP AG 2002, Using the CTS with SAP BW 2

Overview

Connecting Systems

Transports in the source system

Transporting Objects in BW

BEx Objects

Transporting BEx Objects

Executing the Transport

BEx Development Classes

Transporting a Role

Standard Transport System

Object Alterability

Transport Strategy

Trouble Shooting

Object Versions

3

Overview

4


Recommended System Landscape

R / 3

B W

R F C R F CR F C

C o n s o l i d a t i o nB 2

P r o d u c t i o nB 3

D e v e l o p m e n tB 1

D e v e l o p m e n tO 1

C o n s o l i d a t i o nO 2

P r o d u c t i o nO 3

A typical system landscape consists of a development, consolidation and production system both on the R/3 and on the BW side. There are no transport routes among the virtual ITS instances. If one ITS service is defined for the development system, it has to be checked in into the corresponding R/3 or BW system. This service will be transported to the next R/3 or BW system and from there it will be checked out into the corresponding ITS instance.

From BW 3.0 Web Application Server is used as a basis, ITS is then no longer necessary for standard web reporting.

5


SAP TMS - Architecture and Terms

Change and Transport System (CTS)

Transport Organizer (CTO)Transport

Management System (TMS)

Transport Tools (low level programs: tp, R3trans)

CTS architecture for BW is the same as for R/3. The same tools / programs are used.

6


CTS - Post Installation Activities

The following activities have to be performed after an installation:n Initialize CTO

n Create / Choose transport directory

n Configure transport control program (tp)

n Configure system landscape

n Configure transport layers and routes

n Check TMS

7


Create transport layers / routes

SAP provides two editors for configuring additional transport routes for more complex system landscapes:

Hierarchical list editor - The BW Systems in the transport domain and their transport routes are displayed in a tree structure.

Graphical editor - The BW Systems and their transport routes are displayed graphically. The BW Systems can be positioned and linked using the mouse. To call the graphical list editor, use Transaction code STMS. Then, choose Overview -> Transport routes.

To create transport routes, use the mouse to drag the appropriate BW Systems from the node area, and drop them in the display area. To create a transport route between these BW Systems, from the screen Display Transport Routes, choose Configuration -> Transport Route -> CreateTransport Route. The mouse pointer becomes a stylus. Using the stylus, draw a line connecting the two BW Systems between which a transport route is desired. In the dialog box CreateTransport Route, enter the required information for either the consolidation or delivery route. Save.

8


Checking TMS

§RFC connection test

§Transport directory check

§Transport control program (tp) check

All BW Systems in a transport domain communicate with each other using RFC connections.

To check these RFC connections in the TMS overview, from the TMS initial screen(TransactionSTMS) choose Overview -> Systems -> R/3 System -> Check -> Connection test. The connection test is performed in both directions . If you find that there are connection problems with BW Systems having several application servers, you can change the server configured for the TMS.

To verify the availabilityof the transport directories of all systems within the domain, from the TMS initial screen (Transaction STMS) choose Overview -> Systems -> R/3 System -> Check -> Transport directory.

To test the transport control program tp , from the TMS initial screen (TransactionSTMS) choose Overview-> Systems -> R/3 System -> Check -> Transport tool.

9

Connecting Systems

10


Connecting Systems

§PI must be installed on R/3 (most current version recommended)

§Transports only between R/3 systems or between BW systems.

§Communication between R/3 and BW systems via RFC.

§Default system setting: New BW objects are created as local objects. Transports of new objects have to be done with the “Transport connection” in the AWB.

You must ensure that the relevant release-dependent extractors are implemented on the R/3 systems, either the so called PI or PI-A (The BW-BCT extractors won’t work). It is recommended to use the most current version of the extractors.

Transports are only possible between R/3 systems (O1, O2 and O3) or BW systems (B1, B2 and B3). It is not possible to transport between R/3 and BW systems. The communication between R/3 and BW systems during the upload process takes place via RFC.

As of BW release 2.0A the Change and Transport Organizer (CTO) component in the BW system is always switched ON. It was possible to switch off CTO in 1.2. There is special logic implemented for BW objects. New BW objects are created as local objects. Transports of new objects have to be done with the “Transport connection” in the AWB. Here dependent objects are collected and the user can assign a non local dev. class and a transport request to the collected objects.

11


Maintain Source System Mapping (Target System)

Different BW systems in the system landscape are connected to different source systems.

During transport source system specific objects (transfer rules) must be converted accordingly.

This is done with a mapping table (RSLOGSYSMAP).Original source system (typically development system) is mapped to target source system (typically consolidation or production system)

For source system specific objects a mappingmust take place during transport:

During metadata upload the metadata will not be assigned to any development class, the uploaded metadata can’t be transported between BW system. The metadata upload has to be done for each pair of systems (R/3 OLTP – BW) separately.

Before transfer structures can be transported between BW systems you have to maintain the conversion table RSLOGSYSMAP (via menu in RSA1 –> Tools –> Mapping of the source system names). The conversion table is maintained in the target BW system, into which the transport will be imported. InfoSources mapped to a source system are converted during the transport using this conversion table.

Before the first transport between the BW systems (B1, B2 and B3) takes place, a metadata upload from the connected R/3 systems to the BW systems should be done in order to avoid possible errors in the transports. For example: If a TransferStructure is transported it can only be activated if the relevant DataSource already exists in the target system.

The original source system is typically the development system for the consolidation system as well as for the production system.

If this entry is missing no mapping takes place and the objects are imported without being transformed.

12


Maintain Source System Mapping (Target System)

Example: In the system B2 you specifythat objects coming from O1 are mappedto be dependent on O2. If the logical

system name of O1, O2 are TB3CLNT003,QB3CLNT003 respectively, mapping in B2looks like below

13


Transport Process

R / 3

B W

R F C R F CR F C

C o n s o l i d a t i o nB 2

P r o d u c t i o nB 3

D e v e l o p m e n tB 1

D e v e l o p m e n tO 1

C o n s o l i d a t i o nO 2

P r o d u c t i o nO 3

33

22

1 1

The BW development system is connected to the R/3 development system. Ensure that the development systems are identical to the production systems with respect to customizing settings and

metadata content. Adjustments to the R/3 production system must be reflected in the R/3 development system. Extractor enhancements (like view names used in RO* tables) and metadata changes are recorded automatically in transport requests. These changes have to be transported from the development system to the consolidation system and further on into the production system.

The BW consolidation system is connected to the R/3 consolidation system. As the consolidation systems are for consolidation issues only, the servers on which these systems are installed can

be servers with smaller configuration. The customer can check / test in these systems the influence of transports to the functionality of the system. Ensure that the consolidation systems are identical to the production systems with respect to customizing settings and metadata content. Adjustments to the R/3 production system must be reflected in the R/3 consolidation system.

The BW production system is connected to the R/3 production system.If available, the extractor enhancements from the R/3 development / consolidation system must be imported into the

R/3 production system. A metadata upload must be carried out in order to make any new metadata available in the BW production system. It is not possible to transport the uploaded metadata from the development BW system into the following systems. This is done because a transport of thesemetadata could lead to inconsistencies in the target system if later a meta data upload will be performed in the target system.

The no change switch for the R/3 system ensures that no repository objects can be changed in the production system. Before 1st transport from B1/B2 do a metadata upload in B2 to avoid possible problems in transports and maintain

conversion table (RSLOGSYSMAP) in B2.From 3.0A on step 2 will be done automatically so there is no user action required.

14

Object Versions

15


Object Versions

lFour object versions in BW:n D - SAP Delivered versionn M - Modified or Changed versionn A - Active versionn T - temporary version for source system dependent objects (like

M-Version, details in note 411574)

lThe Active version is the one exported in a transport request -make sure correct version is active before transporting!

16


SAP BW Object Versions

delivery from SAP

11

Version

M(odified)

A(ctive)

An upgrade of the Business Content does not affect the objects which are in productive use.

D(elivery)

11

11

22

2nd deliveryfrom SAP

install BC

11

11

11

11 11

2nd install(match) BC

11

22

22

22

22 22

The objects of the Business Content are delivered in delivery version.

Changes are stored in modified version.

Active Business Content is stored in active version.

Only objects in the active version are exported from the development system. When importing to the target system, these objects are either imported directly to the active version, or to the modified version, depending on the type of object.

Currency translation types and InfoObject catalogs are examples of objects that are imported in active version.

InfoObjects and InfoCubes are examples of objects that are first imported to modified version and then activated after the import.

17


Metadata: Versions and Transport

lAll BW meta objects are activated by the common After Import Method RS_AFTER_IMPORT

M(odified)

create

A(ctive)

activate

11

11

change

11

11

22Source system

export

import

M(odified)

A(ctive)

11

11

change

11

11

44

Target system

33

After import method

All modifications made to BW meta objects are written to change requests

After releasing a change request the active versions of the contained objects are exported from the source system to the file system

When the change request is imported in the target system the objects are written to the modified version

After the import is finished the so called “After Import Methods” are executed. These methods try to activate the imported objects. Dependencies between the objects (e.g. InfoObjects have to be activated before InfoCubes are activated) are resolved in this step.

If the after import activation fails, the old active version of the object can still be used

18


19



l For BW 2.0 there are only two objects (DataSource and applicationhierarchy for data sources) to be transported on the source system side

l DataSources have an automatic transport connection

l The application hierarchy needs to be tranported manually (note382471)

l Don‘t forget to transport enhancements (user exits), check whether project is active

If you use business content data sources you can either transport them or activate them in your source systems.

If you are using CO-PA please read notes 325902, 334991.

20


Manual Transport (of Several DataSources, RSA6) is also possible

Select DataSources to Transport

This feature can be used if you want to manually create a transport request with several DataSources, e.g. if a new system should be provided with thoseDataSources.

21


Data Source Maintenance (RSO2): Change Object Directory Entry Manually

First, select ‘DataSource’ -> ‘Object directory’

*Dev. class has not been maintained

Choose a transportable Dev. class

You can manually change the development class of a DataSource in the maintenance transaction, e.g. if you have created a DataSource as a local object.

22


Replicate DataSources in BW (Target System)

First, select ‘Source Systems’

Then, choose a ‘Source System’

Finally, select ‘DataSource overview’ to replicate one or several DataSources

Select ‘Replicate DataSources’ to replicate ALL DataSources from the source system

23


Replicate DataSources

In this case only the selected DataSource will be updated from the source system.

24

Transporting Objects in BW

25


Grouping

lIn the menu Grouping you can determine how many objects should be taken into consideration. The groupings summarize all the objects of an area.

lThe setting “Save for system copy” means that the source system dependent objects are collected in a transport request. This request can be imported after a system copy (of BW or source system) in order to map those objects to the correct source system (with mapping table described above).

Details about system copies of BW systems are described in note 184754.

26


SAP BW Metadata Visualized: Flow of Information

source system

transferrule

InfoSource updaterule

infoCube query workbook role

l The graphic is embedded in an HTML page and encoded in VML(XML based Vector Markup Language).

l VML is supported by Internet Explorer 5 and other vendors. It isnot available in IE 4.

l When the graphic was created, no source system was available with data for the upper InfoSource. Hence, no transfer rules ... would be created during Business Content installation.

27


Maintain Source system assignment for object collector

Source system dependent objects are only collected (for transport) if the corresponding source system is assigned here.

At least one source system needs to be assigned.

In general all source systems should be assigned that have a corresponding source system in the target BW system, however, this is only a default for the object collector. You can still suppress transport of such objects after they have been collected, if you don t want to transport for all source systems.

28


Collection mode

lIn the menu Collection mode, you can determine how you want to collect data. With collect automatically, the data is collected directly when selecting objects. With start manual collection, the data is collected by first choosing the pushbutton gather dependent objects.

29


Transport Object Selection

lChoose how you want to view the objects:n Data Targets by InfoAreasn InfoObjects by Application

Componentn InfoSources by Application

Componentn Rolesn Object Types

n Development Classes

30


Transports connection

1. Select one or several objects

2. Drag & Drop objects (or use context menu)

3. Write to transport request

New Objects (Development Class $TMP) are marked

automatically

31


Transport Information

lObjects that are not yet assigned to a transportable development class are automatically flagged for transport

lOther objects can be flagged manually if e.g. import failed and transport should be redone (might already be locked by other requests, though)

lAdditional information is also available:n Last changed on/byn Last changed by

n Transport requestn Transport order holder

n Development class

32


Transporting BW Objects

Select ‘Transport objects’

33


Transport BW Objects For the First Time

Replace ‘$TMP’ with a relevant Development class

(customer: Y*, Z*)

Create a request or choose an existing one

Create and use your own development classes, don‘t use SAP development classes.

34


Check Transport Status

Check status of transport

If there are dependent objects already written to other transport requests make sure those other requests are released in time.

35


Transporting Changes After First Transport

After assignment of a transportable development class BW objectshave an automatic transport connection.

Still they can be transported again with the BW transport connection (they could be locked, though!)

lAWB objects are handled in the standard way

lFor BEx objects there is a special implementation as follows

After an object has been assigned to a transportable development class (usuallyafter the first transport) changes to those objects are automatically recorded.

BEx obejcts are then handled in a special way but AWB objects are treated in the standard way, i.e. the user is asked for a change request when changing such objects.

Still those objects can be transported manually using the transport connection. By default they are not marked for transport but they are collected and you can mark them manually to be transported.

36

Transport of BExObjects

37


BEx Objects

lBEx objects relevant to transport are:n Workbooksn Queriesn Structuresn Restricted Key Figures

n Calculated Key Figuresn Variables

From 3.0A on we have additional BEx Objects:

Templates

Query Views

Items

38


Transport of BEx objects

lFor BEx objects, the first transport works as described above.

lWhile making changes to the BEx objects which are no longer $TMP, the system records the changes to a pre-assigned CTS Request. n There is one CTS Request, for example, ”Standard CTS Request" where

changes to the BEx objects can be recorded.n You can also specify the CTS Request by Development class.

lThe end user is not prompted for the Request at all.

39


Assigning Changes of BEx Objects

lThe system has a two level process for choosing the CTS Request for recording the changes. n First, the system looks for the CTS Request which is assigned to the

development class of the BEx object. n If it’s not found then use the “Standard CTS Request”.

40

Setting Up the BEx Development

Classes

41


Maintain ‘Request BEx’

Select ‘Request BEx’

If this has already been maintained, then this

message appears

This button will no longer be available in BW 3.0 (see below)

42


Change the ‘Standard BEx transport request’

To change the Standard BEx

transport request, select ‘BEx

development classes’

43


Reassign ‘Standard BEx transport request’

The ‘Standard BExtransport request’ is

visible here. To change this, select

‘Assign / delete’

The standard transport request can be assigned here (additionally to the way shown before).

From 3.0A on this will be the only way to assign / change the standard transport request.

44


New transport request for BEx

Create a new transport request, or choose an existing

one.

45


Add a Development class

Select ‘Insert row’

Then Enter the development class

46


Request Assigned to Development class

Create a new transport request (Workbench), or

choose an existing one.

The Development class now has a

Request assigned.

47


Changing a request for a development class

Highlight the transport request,

and then select ‘Change request’

48

Executing the Transport

49


Transport Organizer (SE09), Development System

Enter the ‘User’

Choose ‘Workbench requests’ for BW

transports

Select ‘Modifiable’ for Request status and

then ‘Display’

50


Releasing a Task

Select the task and then ‘Release directly’

51


Creating Documentation

Enter any documentation on this

transport that is needed. Once finished select ‘Save’ and then

‘Back’

52


Releasing the Request

Now that the Task has been released

successfully, select the Request and then

‘Release directly’. Make sure other requests (with

necessary related objects) have been

released before

53


Task and Request Released

Since both the Task and Request have

been released successfully, this can now be transported to

the target system

Make sure that requests with dependent objects are released in the right order.

54


Import Transport Request (STMS), Target System


55


Import Queues


56


Import Queue

Import highlighted request

Import All (entire queue)


57

Transporting a Role

58


Transporting Roles

lRoles are customizing objects so you need a customizing request.

lRoles that are delivered in the SAP Business Content can be transported via the Transport connection.

lCustomer-defined Roles can also be transported manually using the rolemaintenance (PFCG).

lWorkbooks that are assigned to a role are transported in a BEx request, so both the customizing request and the BEx request need to be transported in order to have a valid link between role and workbook in the target system

59


Transporting Roles (RSOR)

60


Transporting a Customer-defined Role (PFCG)

First, select an existing ‘Role’

Next, choose ‘Transport role’

61


Information about Transporting Roles

62


Transporting Role objects

These options allow you to transport Role objects along with

the Role

63


Additional Information

64

Standard Transport System (automatic

transport connection)

65


Standard Transport System Activation in BW

n The developers should choose a development class and a request, immediately when creating a new object. (automatic transport connection for all objects)

n Advantages:u Maintenance with object collector not requiredu Change authorizations via tasksu Easier maintenance for several development classes

n To activate the standard transport system, you must set field TADIRPOPUP of table RSADMINS for ID 'BW' to 'X'. Before Support Package 18 (2.0B) you achieve this with the following small program:

UPDATE rsadmins SET tadirpopup = 'X'

WHERE customizid = 'BW'.

Enter the program in Transaction SE38 and execute it.

From Support Package 18 on, this will be changeable from the menu

(note 356018)

You want to activate the standard transport system in BW. In BW, new objects first are created automatically as local with development class $TMP. Consequently, no dialog box is displayed first when you create a new object in which you could write the object to a transport request. When you transport the objects for the first time, these objects and dependent objects must be collected in the transport connection of the Administrator Workbench first. A transportable development class is assigned after this and the objects are written to a request.

This procedure has the advantage that first you need not take care of the transport during the development of new scenarios. After the scenario has been completed , you only have to collect the objects that are required in the production system in the transport connection and write them to a request. The objects not required remain there as internal objects and are not transported. If you write all objects immediately to requests, it can happen that test objects and productive objects are mixed on one request. In this case, it is complicated to clean up the requests.

If you activate the standard transport system you don’t have to use the object collector but you still have to take care of releasing transport requests in the right order. Authorizations can be handled by tasks in the standard way. The users might not have the authorizations to create requests /tasks, so they can only change objects if the administrator has created a task for them. Especially when working with different development classes the standard transport system makes correct assignments easier because you decide your assignment for each single object.

66


(cont.)

lCAUTION!

lOnly the newly created objects are recorded from now on. You might still have to transport the old objects via the transport connection of the Administrator Workbench.

67

Object Alterability

68


Changing Object Types

Use these settings for system that are “nod modifiable”. Afterwards, the specified objects can then be changed despite the system settings.

More details and latest information in note 337950

69

Transport Strategy

70


Transport Strategy Considerations

lWhat is my system landscape?

lHow many different projects are working on that system?

lHow complex are my scenarios?

lWho is responsible for transports / development classes (central, decentral)?

lWhich kind of system (development, consolidation, production)?

lHow can the transport of BEx objects be organized?

71


System Landscape

lIn a standard three system landscape one development class may be sufficient, transport using object collector

lIn a complex landscape different objects might have to be transported to different system (different development classes, transport layers). There are typically some common objects that need to be transported to all systems and some specific ones

72


Number of Projects on a System

lBasically the system landscape considerations also apply for projects

lYou have to distinguish between common objects and project specific ones

lYou may want to be prepared to split up into different systems later on (e.g. for performance reasons)

73


Complexity of Scenarios

lIn very complex scenarios dependencies of objects can also be complex

lActivating automatic transport connection ensures that no objects are forgotten but the order of the imports is then very important

lThe object collector helps you find the dependent objects but transport requests may contain many objects

lIn case of problems split up transports (into parts of the data flow)

74


Responsibility

lIf you have complex scenarios / system landscape / several projects organizing transport may be a crucial issue

lCentral management may be necessary to decide

l Which object is assigned to which development class

l Which objects are collected in one transport request

l In which order and when do the transports take place

75


Type of System

lThe above considerations are focussed mainly on development systems

lYou may want to create some objects in the consolidation system in exceptional cases. Activation of automatic transport connection for keeping track of all such objects / changes may be a good approach

lIn the productive system you typically don‘t create objects to be transported but e.g. queries (ad hoc reporting). Using default BW setting (no automatictransport connection) is usually the best option (independent of settings in development or consolidation systems)

76


Transport of BEx Objects

lSince BEx Objects (once they are assigned to a transportable developmentclass) are transported in a special way there are special considerations:

lAll changes of BEx objects (in one development class) in a certain period are transported together (unless standard transport system is activated)

lGranularity of development classes for BEx objects is important for flexibility in transports, e.g.

l On project level

l On data target level

l Several ones for each data target

l One for each query

lTransport management of BEx requests

l Agreement on when transport request is released

l Creation of a new one immediately after (or before) releasing the old one

The only way of grouping BEx objects in a transport (after first transport) is by development class. So you have to determine the granularity you need for transporting BEx objects and set up development classes accordingly.

No changes to BEx objects are possible if

No BEx request exists

The old BEx request is released and no new one is created

A new BEx request is already assigned but the old one has not been released

77

Trouble Shooting

78


Transport Problem when Saving Queries

lIn the BEx Analyzer, a user attempts to save a query and receives the following error:n "The query could not be saved due to a problem in transport”

lCheck whether the BEx default transport request or the development class-dependent transport request is maintained or released.

lThe error only occurs for query objects which already have a transportable development class.

79


Problems Creating Change Request

Objects already assigned to a transportable development class could be locked (already contained in an unreleased request)

Expand tree and check “change request” column in BW transport connection

As of SP 16 (BW 2.0B) a log is displayed with this information

More details in note 407485

80


Activation Problems After Import

Analyze transport protocol, check for error messages in after import method

If objects are missing or not in the latest version include them and the original one(s) in another transport (if they are locked release transport requests)

If objects are not activated because of potential loss of data correct error in original system (or delete data if applicable)

Try manual activation in target system (e.g. if table conversion is necessary, if number range objects are missing)

Buffered (old) information might be used for activation (solved with SP 14 for InfoObjects, SP17 for texts). Repeat import after buffer synchronisation

Manual conversion of an InfoObject is only necessary if characteristics are deleted from compounding or fields from text table, attribute changes are done automatically

More details in notes

125499 Activation error after transport of BW objects (manual conversion of tables with SE14 might be necessary)

381924 The InfoObject import terminates (BRAIN049)

411574 Method execution with RSDG_AFTER_IMPORT_FOR_CORR

376173 Objects (texts) are missing after transport (though they have been imported)

81


Problems With Transported Workbooks

Workbooks (along with dependent views, web templates…) are located in BDS

Problems might be caused by BW objects or by BDS itself.

Note 315687, Old versions displayed after transport (BDS)

In BW 3.0 views, templates and items are transport objects (independent of workbooks)

82


Problem with Source System Dependencies

Error messages: “Data source doesn’t exist” or “field not delivered by source system” might come up

Activate Data Source (again) from Business Content (if applicable) or

Transport DataSource (again)

Replicate DataSource

Import your transport again

In case of a file source system create another transport requestcontaining also the data source (select all)

More details in note 360951

83


Problems Transporting a DataSource

If a self-created DataSource is transported with RSA6 the extract-structure is not automatically transported with the DataSource

(error message in target system: Only transparent tables and database views can be extracted)

Find corresponding extract structure in table ROOSOURCE and include it in a transport (TLOGO: R3TR TABL)

84


Additional Remarks

Hierarchies are considered data (not metadata)

So they can be loaded (normal staging)

They can not be transported

Currency exchange rates are also loaded from the source system(s), not transported

85


Additional Remarks (2)

Assignments of reporting authorization objects to InfoCubes / ODS objects and hierarchy authorizations need to be transported manually in transaction RSSM

Press button “(Transport) Additional Info”

Choose the reporting authorization object(s) you want to transport information for

Select hierarchy authorization(s) you want to transport if applicable

Create or choose a transport request for this information

86


Copyright 2001 SAP AG (All rights reserved)

n No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

n Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

n Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

n IBM ®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

n ORACLE® is a registered trademark of ORACLE Corporation.

n INFORMIX®-OnLine for SAP and Informix® Dynamic ServerTM are registered trademarks of Informix Software Incorporated.

n UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

n Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

n HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

n JAVA® is a registered trademark of Sun Microsystems, Inc.

n JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

n SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink , SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respe ctive companies.

CTS_with_SAP_BW

Documents

Transcript of CTS_with_SAP_BW