The Transaction Layer on the mobile client handles the access to the native database. On the identical time (i.e. in the identical COMMIT cycle), it shops the info in a local queue in a format that can then be transferred to the server.When the person decides to start the communication course of by invoking the ConnTrans program, the Connection Supervisor on the shopper aspect establishes the connection to the server after which activates the Message Transfer Service, which transfers the info to the server by calling the Switch Proxy on the Communication Station. Different switch services might be included within the connection session, so that the person has to provoke the communication solely once.
DCOM is used for consumer/server communication. The DCOM Part Connector, an SAP middle ware product, acts as the interface between the Microsoft and ABAP environments by making RFC perform calls available as COM components.The DCOM Part Connector translates the DCOM perform calls from the Message Transfer Service into RFC perform calls to the Inbound Adapter on the CRM Server. The incoming DCOM function calls are not queued or stored on the Communication Station.On the shopper facet the Connection Supervisor triggers the Transaction Layer to read the inbound queue when new data arrived.
There are two principal reasons to run the Microsoft Transaction Server (MTS) on the Communication Station: increased safety (authentication) and better efficiency (connection pooling).
COM Object as Connection Interface
The Message Transfer Service calls strategies of a COM object on the Communication Station. The Transfer Proxy translates COM operate calls into qRFC perform calls.The DCOM and qRFC operate calls comprise BDocs
Connection with Mobile Client
On the networking level it's ample to provide a TCP/IP connection to the Communication Station.When installing the Cellular Consumer application, you would possibly be requested whether to modify replication on or off. If the replication is switched off, the installation routine gives a pre-stuffed database for the client application. In this case, it is not potential to exchange information with the CRM Middleware. In case you enable replication, you are requested for the IP deal with of the communication station.The QmtCheck.exe program could also be used to test the DCOM connection between the cell purchasers and the Communication Station. It can be launched on the mobile shoppers through the Client Console.
The settings for the DCOM connection might be specified utilizing the program dcomcnfg.exe. For the safe first communication, an RFC connection between the shopper and the CRM Middleware has to be established once. This RFC connection is configured and used by the program ASiteID (it can be referred to as by manner of the Consumer Console), which requires that the customers and the cellular clients are already identified on the CRM Server. The user and websites administration on the CRM Middleware in addition to the safe first communication will likely be mentioned in the Unit Replication & Realignment Overview.
Communication Status
The set up of the connection between the Communication Station and the CRM Middleware involves the next steps:
The MTS is completely integrated into the Home windows NT safety mechanism. It affords two sorts of safety administration:
Secure Initial Connection
To make sure a secure communication between a Cell Consumer and the CRM Middleware, a secure first connection protocol is used.A web site ID and a consumer for a newly installed Cellular Client are created within the CRM Middleware utilizing the Administration Console.On the Cellular Consumer laptop computer, this system “Assign Web site ID” is began using the Client Console to join with the CRM Middleware. Throughout this first secure connection, a novel website ID is transferred from the CRM system to the cellular client.During subsequent connections, the consumer identifies itself utilizing the site ID and a generated key (the Site ID is utilized by the ConnTrans program); CRM Server logon is not required.The assigned subscription knowledge is ready on the CRM Server within the outbound queue for the Site. The
list of crucial subscriptions is challenge dependent and must be recognized throughout implementation section,but at the very least contains worker, consumer (incl. logon) and authorization data.
The Cell Shopper can now provoke a communication (ConnTrans) for the first time to obtain the info wanted for the mobile application.
Consolidation Data Base
The information for cell shoppers is kept in separate tables on the CRM Server for performance and replication reasons. These tables are referred to as Consolidated Database (CDB). From the technical point of view the Consolidated Database is just a set of tables inside the physical database of the CRM server.The information model for cellular shoppers is clearly structured, therefore, a data conversion is necessary. The CDB accommodates the already converted data. Furthermore these tables are required for delta information calculations, so that the BDoc messages despatched to cellular purchasers solely contain the modified fields. This reduces the amount of knowledge despatched to cellular clients. In addition, complicated replication scenarios containing dependencies and information redistribution (realignment) can only be effectively supported utilizing the CDB.
BDoc and Data Flow
Messaging move utilizing mBDocs is an infrastructure for transferring knowledge to the CRM Server Purposes within the CRM Server and from/to exterior systems. The “philosophy” of an mBDoc is mainly that of a brief knowledge container (not not like an IDoc which is a persistent data container).After an mBDoc has been delivered, its ceases to exist and its standing is unimportant. Synchronization circulation utilizing sBDocs is an infrastructure particularly designed for the extremely distributed cellular scenario.
Because of the large number of databases equipped with information it's essential to optimize the data quantity replicated.Because of the limited sources of a mobile Shopper, it can't get all of the data. Replication rules should be defined.When the Replication rules are modified, it must be attainable to find out who received what information in order to adjust the information distribution (=> Realignment). The status of sBDoc replication is due to this fact stored in so-known as look-up tables.For a Realignment it has to be doable to simply extract the new information for a Cellular Client.Synchronization and messaging flows are linked through mapping providers.
Minor and Major Realignments
Realignment is a redistribution of information that ensures that each one websites receive the info assigned to them by way of subscription. It has to be certain that that the distributed native databases stay according to the standing of the central Consolidated Database.A minor realignment is triggered by changes to knowledge, i.e. when a value of a criteria field is changed. In this case deletion or replace BDoc messages are replicated to the Mobile Clients.A serious realignment is triggered by modifications to subscriptions, i.e. when creating or deleting subscriptions. On this case the corresponding deletion or creation messages for the BDoc messages belonging to the subscriptions are replicated to the Mobile Clients.
The minor realignment is applied to single BDoc instances.It takes place, for instance, once you:Create an object (i.e. BDoc occasion): Knowledge is extracted to all relevant sites together with all dependent BDoc instances
Choose the Search function and suppose about the search results. For every session discovered, a record containing data on this session seems in the table at the upper proper-hand side of the screen.
3. Double-click on one of the sessions displayed. The corresponding document is marked green and detailed data on this session appears in the Session Details tab on the decrease right-hand side of the screen.
Monitoring Mobile Server
The Cellular Client Message Recovery shows the standing of BDoc messages sent from the CRM Server to the Mobile Clients (inbound processing) and permits the reprocessing:
Queue Monitoring
The five replication and realignment queues are used for Cell Clients only.The replication and realignment queues are displayed for the current client:
Bdoc Layer in Mobile Client
The BDoc Sort Metadata holds the buildings of the BDoc types in one cache file on operating system level for efficiency reasons. With out a cache file this information should be recovered from multiple database tables for each BDoc message, which is obtained from the CRM Server. The title of the cache file is TLCache.tps, which stands for Transaction Layer Cache, the previous identify of the BDoc Layer. The suffix .tps stands for Transaction Layer Persistent Storage.
Related Posts
SAP CRM Technology Overview
CRM Data Exchange with SAP R/3
CRM Data Exchange via Adapter
CRM E commerce Introduction
CRM Interaction Center System Architecture
DATA BASE UPDATES AN OVERVIEW DAY 45
LWS AND CLIENT SERVER DAY 46
SAP LOCK CONCEPT DAY 47
DCOM is used for consumer/server communication. The DCOM Part Connector, an SAP middle ware product, acts as the interface between the Microsoft and ABAP environments by making RFC perform calls available as COM components.The DCOM Part Connector translates the DCOM perform calls from the Message Transfer Service into RFC perform calls to the Inbound Adapter on the CRM Server. The incoming DCOM function calls are not queued or stored on the Communication Station.On the shopper facet the Connection Supervisor triggers the Transaction Layer to read the inbound queue when new data arrived.
There are two principal reasons to run the Microsoft Transaction Server (MTS) on the Communication Station: increased safety (authentication) and better efficiency (connection pooling).
COM Object as Connection Interface
The Message Transfer Service calls strategies of a COM object on the Communication Station. The Transfer Proxy translates COM operate calls into qRFC perform calls.The DCOM and qRFC operate calls comprise BDocs
- Connection between
- SAP components (written in ABAP or ABAP Objects) and
- COM components (written in VB, Java, C++, Cobol, Delphi, etc.)
- Component Object Model (COM) is an open architecture for cross-platform growth of consumer/server purposes based on object-oriented programming. The functions and programs may even be supplied by totally different vendors. This expertise supports growth in varied programming languages. With the COM technology, shoppers have entry to an object by means of interfaces implemented on that object. COM is language-independent, so that any language that produces ActiveX parts may also produce COM applications.
- Distributed COM (DCOM) enables COM software program components to communicate directly over a network, e.g. between a cell client and the CRM Middleware.
Connection with Mobile Client
On the networking level it's ample to provide a TCP/IP connection to the Communication Station.When installing the Cellular Consumer application, you would possibly be requested whether to modify replication on or off. If the replication is switched off, the installation routine gives a pre-stuffed database for the client application. In this case, it is not potential to exchange information with the CRM Middleware. In case you enable replication, you are requested for the IP deal with of the communication station.The QmtCheck.exe program could also be used to test the DCOM connection between the cell purchasers and the Communication Station. It can be launched on the mobile shoppers through the Client Console.
The settings for the DCOM connection might be specified utilizing the program dcomcnfg.exe. For the safe first communication, an RFC connection between the shopper and the CRM Middleware has to be established once. This RFC connection is configured and used by the program ASiteID (it can be referred to as by manner of the Consumer Console), which requires that the customers and the cellular clients are already identified on the CRM Server. The user and websites administration on the CRM Middleware in addition to the safe first communication will likely be mentioned in the Unit Replication & Realignment Overview.
Communication Status
The set up of the connection between the Communication Station and the CRM Middleware involves the next steps:
- The MTS security setting need to be specified. This specifies the authentication level and knowledge encryption between the cellular client and the Communication Station.
- An RFC vacation spot has to be defined in the DCOM Element Connection on the Communication Station.
- The communication between the Communication Station and the Middleware will be tested using the program QmtCheck.
The MTS is completely integrated into the Home windows NT safety mechanism. It affords two sorts of safety administration:
- declarative security (controls entry to the enterprise objects and denies access to users who do not have the required privileges)
- programmatic security (allows the business object itself to decide what the person is allowed to do; it has extra detailed security checks than the declarative safety)
- Start the MTS Explorer from the menu
- On the precise hand aspect of the window there might be an icon with several hats. A quantity of users can be assigned to every role. The definition of roles is barely valid for a specific package and for parts contained on this package. A task can contain a quantity of Home windows NT users/groups.
- A package is a form of container for quite quite a bit of parts which often serve a related purpose.
Secure Initial ConnectionTo make sure a secure communication between a Cell Consumer and the CRM Middleware, a secure first connection protocol is used.A web site ID and a consumer for a newly installed Cellular Client are created within the CRM Middleware utilizing the Administration Console.On the Cellular Consumer laptop computer, this system “Assign Web site ID” is began using the Client Console to join with the CRM Middleware. Throughout this first secure connection, a novel website ID is transferred from the CRM system to the cellular client.During subsequent connections, the consumer identifies itself utilizing the site ID and a generated key (the Site ID is utilized by the ConnTrans program); CRM Server logon is not required.The assigned subscription knowledge is ready on the CRM Server within the outbound queue for the Site. The
list of crucial subscriptions is challenge dependent and must be recognized throughout implementation section,but at the very least contains worker, consumer (incl. logon) and authorization data.
The Cell Shopper can now provoke a communication (ConnTrans) for the first time to obtain the info wanted for the mobile application.
Consolidation Data Base
The information for cell shoppers is kept in separate tables on the CRM Server for performance and replication reasons. These tables are referred to as Consolidated Database (CDB). From the technical point of view the Consolidated Database is just a set of tables inside the physical database of the CRM server.The information model for cellular shoppers is clearly structured, therefore, a data conversion is necessary. The CDB accommodates the already converted data. Furthermore these tables are required for delta information calculations, so that the BDoc messages despatched to cellular purchasers solely contain the modified fields. This reduces the amount of knowledge despatched to cellular clients. In addition, complicated replication scenarios containing dependencies and information redistribution (realignment) can only be effectively supported utilizing the CDB.
BDoc and Data FlowMessaging move utilizing mBDocs is an infrastructure for transferring knowledge to the CRM Server Purposes within the CRM Server and from/to exterior systems. The “philosophy” of an mBDoc is mainly that of a brief knowledge container (not not like an IDoc which is a persistent data container).After an mBDoc has been delivered, its ceases to exist and its standing is unimportant. Synchronization circulation utilizing sBDocs is an infrastructure particularly designed for the extremely distributed cellular scenario.
Because of the large number of databases equipped with information it's essential to optimize the data quantity replicated.Because of the limited sources of a mobile Shopper, it can't get all of the data. Replication rules should be defined.When the Replication rules are modified, it must be attainable to find out who received what information in order to adjust the information distribution (=> Realignment). The status of sBDoc replication is due to this fact stored in so-known as look-up tables.For a Realignment it has to be doable to simply extract the new information for a Cellular Client.Synchronization and messaging flows are linked through mapping providers.
Minor and Major Realignments
Realignment is a redistribution of information that ensures that each one websites receive the info assigned to them by way of subscription. It has to be certain that that the distributed native databases stay according to the standing of the central Consolidated Database.A minor realignment is triggered by changes to knowledge, i.e. when a value of a criteria field is changed. In this case deletion or replace BDoc messages are replicated to the Mobile Clients.A serious realignment is triggered by modifications to subscriptions, i.e. when creating or deleting subscriptions. On this case the corresponding deletion or creation messages for the BDoc messages belonging to the subscriptions are replicated to the Mobile Clients.
The minor realignment is applied to single BDoc instances.It takes place, for instance, once you:Create an object (i.e. BDoc occasion): Knowledge is extracted to all relevant sites together with all dependent BDoc instances
Choose the Search function and suppose about the search results. For every session discovered, a record containing data on this session seems in the table at the upper proper-hand side of the screen.
3. Double-click on one of the sessions displayed. The corresponding document is marked green and detailed data on this session appears in the Session Details tab on the decrease right-hand side of the screen.
Monitoring Mobile Server
The Cellular Client Message Recovery shows the standing of BDoc messages sent from the CRM Server to the Mobile Clients (inbound processing) and permits the reprocessing:
- Processed messages have successfully been processed from the inbound queue into the database of the mobile Client.
- Unprocessed messages could not be saved on the consumer database. These BDoc messages are deleted by the system, a reporting message is sent to the CRM Server. The corresponding BDoc messages might be sent again to the Mobile Shopper by calling the transaction Message Recovery.
- The complete info on the BDoc message standing on the Cellular Client can be accessed through the Consumer Console.
Queue Monitoring
The five replication and realignment queues are used for Cell Clients only.The replication and realignment queues are displayed for the current client:
- The AC_EXTRACT queue represents those extract jobs triggered instantly by the Administration Console.
- The EXTRACTBLK queue is used for extract requests of bulk-replicated BDoc messages.
- ?? EXTRACT, REALIGN and SUBCHECK are used for replication and realignment. Replication queues could be stopped and started manually by clicking on the site visitors gentle - the sunshine modifications between crimson and yellow or green.
- Normally all queues needs to be working or waiting - batch jobs within the background are automatically triggered to course of queue entries when such entries are entered into the queue by the Queue Demon.
- The number displayed next to a queue represents the number of entries at present within the queue. This quantity must be repeatedly reducing, unless new entries are entered into the queue on the identical time. By clicking on the number itself, the entries within the respective queue could be viewed.
- If the number of entries in a queue remains fixed for a period of time, check whether or not the Queue Demon has the standing RUNNING.
Bdoc Layer in Mobile Client
The BDoc Sort Metadata holds the buildings of the BDoc types in one cache file on operating system level for efficiency reasons. With out a cache file this information should be recovered from multiple database tables for each BDoc message, which is obtained from the CRM Server. The title of the cache file is TLCache.tps, which stands for Transaction Layer Cache, the previous identify of the BDoc Layer. The suffix .tps stands for Transaction Layer Persistent Storage.
Related Posts
SAP CRM Technology Overview
CRM Data Exchange with SAP R/3
CRM Data Exchange via Adapter
CRM E commerce Introduction
CRM Interaction Center System Architecture
DATA BASE UPDATES AN OVERVIEW DAY 45
LWS AND CLIENT SERVER DAY 46
SAP LOCK CONCEPT DAY 47
No comments :
Post a Comment