This is the first part of the three part series that I intend to write. I have kept it as short and precise as possible. Hope you find it useful. PART I : Introduction to IPC on MSA 5.0 PART II : Request-Response Explained PART III : IPC on MSA 5.0 In-Depth Introduction The IPC is the ‘Internet Pricing and Configurator’. It is a Java-based client-server package. It provides R/3 pricing and R/3 product configuration outside of an R/3 system. It is made up of several components: • The Sales Pricing Engine, or SPE • The Sales Configuration Engine, or SCE • The Product Modeling Environment, or PME In addition, it has Java Server Page (JSP) front ends and a Java UI. The JSP front ends are integrated into the different CRM scenarios (telesales, internet sales, mobile sales, etc). The IPC is typically used in a CRM scenario, using the CRM database (for Telesales and Internet Sales). It uses the Mobile Sales database (called IDES) in case of Mobile Sales Application. The data in this database is downloaded from the CRM Server database which may get it from R/3. Basic Function To enable consistent pricing and configuration through all sales channels, without needing an online R/3 system, whilst still maintaining pricing and configuration data in one place. IPC in Mobile Sales (MSA) The IPC server in the Mobile Sales scenario is a stripped down version of the IPC server used by the CRM Server. IPC client (in this case Mobile Sales) and server communicate via a simple handshake protocol. The communication medium that is being used is standard TCP/IP sockets. Protocol
The communications protocol used by IPC has been designed to work with minimal requirements concerning the client machine. Client/Server communication consists of a number of communication steps. Each step is initiated by the client sending a request to the server. The server will then process the request and send its reply back to the client. There is no server-driven communication (i.e. the client cannot simply wait for the server to send data), and it is not possible that the server returns more than one response to the client. The diagram above shows details on the client server communication. Both the request and the response are encoded in strings. Since the server is implemented in Java, the characters of the string are not ASCII but Unicode characters. The actual strings have been designed with HTTP in mind. Requests and responses are similar: they consist of a header containing basic information and a body containing the actual data that are being transmitted.
The communications protocol used by IPC has been designed to work with minimal requirements concerning the client machine. Client/Server communication consists of a number of communication steps. Each step is initiated by the client sending a request to the server. The server will then process the request and send its reply back to the client. There is no server-driven communication (i.e. the client cannot simply wait for the server to send data), and it is not possible that the server returns more than one response to the client. The diagram above shows details on the client server communication. Both the request and the response are encoded in strings. Since the server is implemented in Java, the characters of the string are not ASCII but Unicode characters. The actual strings have been designed with HTTP in mind. Requests and responses are similar: they consist of a header containing basic information and a body containing the actual data that are being transmitted.
5 Comments
