Understanding message flow in XI

Hi,
In Understanding message flow in XI  /people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi
1. What is API and SPI.
2. In return diagram What is the functionality of "servlet"

Hello Anil,
<b>An application programming interface (API)</b> is a source code interface that a computer system or program library provides to support requests for services to be made of it by a computer program. An API differs from an application binary interface in that it is specified in terms of a programming language that can be compiled when an application is built, rather than an explicit low level description of how data is laid out in memory.
The software that provides the functionality described by an API is said to be an implementation of the API. The API itself is abstract, in that it specifies an interface and does not get involved with implementation details.
Two well known APIs are the Single UNIX Specification and the Microsoft Windows API.
An API is often a part of a software development kit (SDK).
The term API is used in two related senses:
A coherent interface consisting of several classes or several sets of related functions or procedures.
A single entry point such as a method, function or procedure.
<b>SPI  : Security Parameters Index</b>

Similar Messages

  • Regarding Message Flow in XI

    Hi Experts,
    I was go through the Blog given by Siva Maranani
    /people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi
    But in this After sending the Xi Message from send Queue to Integration Engine...
    What wi be the process inside this IE.
    Please let me know
    Regards
    Khanna

    <i>But as per my knowledge in the IS the Pipeline services wil be done( Includes Receiver det, Interface Det, Mapping, Logical rout, Tech. routing, Call Adapter, Message Split )
    It means there is no further process inside the IE??????????</i>
    Messages received at the Integration Server are processed through a defined series of steps called Pipeline Services. These pipeline services are part of Integration Engine which in turn is a part of Integration Server
    <i>Only the XI Adapter wil pick the Xi msg from Send Queue to IE.......Thats it?????/</i>
    Yes. Thats the main task of XI Adapter. It also does the SLD lookup.
    <i>
    then this IE wil pass this XI Msg to the IS ..... Right????????</i>
    As mentioned, IE is part of IS
    Regards,
    Prateek

  • Message flow from XI To Receiver

    Hi ,
    There are several IDOC to JDBC scenarios running in our XI PRD server but now all the IDOCs are reaching XI,which is visible in IDX5 or SXMB_MONI but nothing has reached the Receiver as visible from Message monitoring.
    In SXMB_MONI , i can see the errors CLIENT RECEIVE FAILED.pls figure out the problem and tell me how to proceed wid.
    Thanx,
    Laawanya

    hi
    as you are doing idoc-jdbc scenario check whether the reciver MT you maintained is of JDBC-XML structure
    check Document Formats for Receiver JDBC adapter
    check the blog for the message flow in xi:
    /people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi
    /people/siva.maranani/blog/2005/09/16/xi-how-to-on-jdbc-receiver-response
    /people/sap.user72/blog/2005/06/01/file-to-jdbc-adapter-using-sap-xi-30
    http://help.sap.com/saphelp_nw04/helpdata/en/2e/96fd3f2d14e869e10000000a155106/content.htm
    Note:please reward points if solution found helpfull
    Regards
    Chandrakanth.k

  • Message flow

    Hi all,
    when the message is sent from sender,how does it go to  receiever..i.e sequence of steps how msg flows from sender to receiver?
    Regards,
    keerthi

    Hi,
    Message flows according to these pipeline steps
    - Inbound message
    - Receiver determination
    - Interface determination
    - Receiver grouping (in case if receiver are more then one)
    - Message branch according to receiver list (in case if receiver are more then one)
    - Request message mapping
    - Technical routing
    -Call Adapter
    -Response
    message comes in the server and depending upon the request of client this is directed to ABAP Stack or Java stack By ICM.
    Also Check out these blogs
    /people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi
    regards
    Aashish Sinha
    PS : Reward points if helpful

  • Message flow direction

    What exactly is the message flow direction ? In a sender system does the message moves from adapter engine to integration server or viceversa ? Similarly in a receiver system does the message move from Integration server to adapter engine ?

    Hi  Radhika,
    The messages are picked up by the sender communication channel, send to resource adapter in adapter engine which does the required formats into xml.
    Then it goes to Module Proccessor and all module works on this in a perticular manner.
    then it goes to in a queue, and all the basic routing and mapping part is done here
    and then it goes to Integration server Messaging Queue.
    To receive the messge from Integration server Messaging Queue and upto receiver end whole process is done in reverse manner.
    If the adapter involved is a Java based adapter, then the flow would be
    Sender - Adapter Engine (sender) - Integration Engine - Adapter Engine (receiver) - Receiver
    If say sender adapter is ABAP based, then it would be
    Sender - Integration Server (Idoc/HTTP Adapter) - Integration Engine - Adapter engine (receiver) - Receiver
    for more clarrification go throgh the following blog
    Understanding message flow in XI
    Regards
    Sridhar Goli

  • ABOUT MESSAGE FLOW

    can any one explaine me how messages flow from sender  to receiver?
    and what occurs in integration engine?
    what is the purpose of icm?

    Hi,
    Have a look at this blog
    <a href="/people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi Message Flow in XI</a> by Siva Maranani
    Regards
    San
    <a href="Remember to set the thread to solved when you have received a solution to set the thread to solved when you have received a solution</a>
    Where There is a <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/weblogs?blog=/weblogs/topic/16">blog</a> there is a Way.

  • Article/References to XI/PI Message Flow

    Does anyone have any good articles or references that show how a message flows into and out of XI/PI?  Im specifically looking for something that shows how the message hits the communication channels and goes through the sender agreements, receiver agreements, interface mappings, etc.

    Message flow in XI look
    /people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi
    Regarding Message Flow in XI
    Pipeline steps look thread
    Pipeline steps?
    pipeline
    Thanks,
    Hetal
    Edited by: hetal shah on Feb 4, 2009 9:28 PM

  • Adapter message flow

    Hi,
      Any one explain the message flow in XI
    Thanks in advance

    Hi Deepan,
    Message flow is the pipeline steps in XI.Pipeline is nothing but the steps performed in integration engine at runtime. After the message is converted to xml in adapter engine it goes to integration engine for processing. In IE these pipeline steps process the message further. These include: receiver determination, interface determination, message split, and mapping, routing, call adapter.
    When a source message reaches the Integration server
    the messages under goes this
    a) Receiver Determination:
    This steps determines the systems that sends and receive the messages.
    b) Interface Determination:
    For each receiver determination there should be an interface to receive the message.
    c) Message Split:
    If more than one receiver are found, XI will instantiate new message for each receiver.
    d) Message Mapping:
    Mapping to transform the source message to destination message format.
    e) Technical Routing:
    Bind a specific destination and protocol to the message.
    f) Call outbound Adapter:
    Send the transformed message to the adapter or a proxy.
    http://help.sap.com/saphelp_nw04/helpdata/en/41/b714f85ffc11d5b3ea0050da403d6a/framese
    More Info in the Blog <a href="/people/siva.maranani/blog/2005/05/25/understanding-message-flow-in-xi Message Flow in XI</a> By Siva Maranani
    Regards
    San

  • Is my  understanding of 'flow of message in XI'  is correct ?

    Hi Xi Experts
       <u><b>Pl..crarify my understanding on XI full flow of message !</b></u>
      If Adapter present : steps
              1) Normal file  will be converted as SOAP XML by using adapter
              2) Adaper will send this SOAP XML message to ICM
              3) ICM will convert the message into XI specific message and send to
                  IS?
              4) All pipe line steps
              5) Then it will reach the target  
    In case of HTTP Protocal:(SOAP)
              1) Here no adapter is required and source message will be converted as
                  SOAP XML and sent to directly to ICM(Using plain Adapter)
              3) ICM will convert the message into XI specific message and send to
                  IS?
              4) All pipe line steps
              5) Then it will reach the target  
    In case of IDOC SAP Sender:
             1) Here no adapter is required and source message will be converted as
                  SOAP XML and sent to directly to ICM(Using ABAP Engine)
              3) ICM will convert the message into XI specific message and send to
                  IS ?
              4) All pipe line steps
              5) Then it will reach the target  
    In Case of Proxies:
              By using ABAP/JAVA proxies we can create XI Specific XML and send to
              IS directly
    This is my understanding after that pipe line
         RD,ID,Mapping, Receiver adapter, Target syatem
    <u><b>Pl... Correct me any where wrong in my understanding of Flow</b></u>
    Thanks for spending your valuable time on my query
    Regards
    Kiran  LVS

    Hi,
    >> In case of IDOC SAP Sender:
    1) Here no adapter is required and source message will be converted as
    SOAP XML and sent to directly to ICM(Using ABAP Engine)
    Since the IDOC Adapter is ABAP stack  The message is sent directly to IE.
    When a source message reaches the Integration server
    the messages under goes this
    a) Receiver Determination:
    This steps determines the system that participates in the exchange of the message.
    b) Interface Detremination:
    For each receiver determine which interface will should receieve the message.
    c) Message Split:
    If more than one receievers are found, XI will instantiate new message for each receiver.
    d) Message Mapping:
    Mapping to transform the source message to destination message format.
    e) Technical Routing:
    Bind a specific destination and protocol to the message.
    f) Call outbound Adapter:
    Send the transformed message to the adapter or a proxy.
    Regards
    Agasthuri Doss

  • BDOC message flow and its architecture

    Hi Expert,
    It can be a simple question but i have a doubt regarding the flow of messages using SAP CRM middleware.
    The scenario is like:
    1. Message flows from ECC to CRM through a BDoc. (It can be opposite way also)
    2. The BDoc fails in CRM due to some data issue.
    3. A BDoc message id is generated.
    4.Now the data is corrected in ECC and initial load was triggered.
    5.The messages are flowing correctly.
    So my doubt is:
    1.What will happen to the old BDoc?
    2. Do the initial or delta load processes the messages with new BDoc ID or through the old BDoc ID?
    3. If the messages are processed through new BDoc id, can the old BDocs be deleted?
    Please help me understand this concepts of BDocs and please provide me to some study material to get more undertsanding of the BDOC message flow architecture.
    thanks,
    Vicky

    Hello Vicky,
    i think I understand exactly what your confusion is all about.
    1.What will happen to the old BDoc?
    The old Bdoc will remain in error state until it is archived or set to processed state.
    2. Do the initial or delta load processes the messages with new BDoc ID or through the old BDoc ID?
    It will be a separate BDoc with a new BDocId. If you get an Error in SMW01 this is beyond the queueing, so later Messages will not get queued behind your faulty bdoc. They will also not "update" your BDoc in any way. Later BDocs will Bypass a bdoc in error state and update your object in CRM if the error in data has been solved in ERP before. If the data error is not corrected, you will get a second failed bdoc.
    3. If the messages are processed through new BDoc id, can the old BDocs be deleted?
    Best practise for the Bdoc with error would be to set it to processed state. That way there is no way that Bdoc can be processed afterwards. The BDoc will then be archived with the next run.
    Best regards,
    Lutz

  • ON PREM Outbound emails showing in dummy non-configured office 365 account message flow trace

    Dear Community,
    We have an on-prem exchange 2013 server and an office 365 account which is completly standalone.
    Whilst the office 365 account is standalone, it does feature the email address we use for on-prem (Ie. the domain name in office 365 account is not active for any office 365 services however has passed ownership verification thus it's just sitting there)
    We DON'T use EOP nor do we have any connector rules on our on-prem system that go to office 365 however when I randomly went into the 'Message Flow Trace' section in our office 365 account, there is recorded outbound mail which was sent from our On-prem
    server.
    The ONLY mail that was recorded in the message Trace in Office 365 was emails we had sent from On-prem to other office 365 accounts (For example btconnect.com, and some of our clients whom also use office 365) .
    How is office 365 picking up mail we've sent from our On-Prem server? Is there integration out of the box in exchange 2013 which auto interfaces with office 365? What on earth has happened here?
    I'm really confused.
    -------- For troubleshooting purposes...
    Headers in the email which arrived in my personal office 365 account from the ON-PREM SERVER
    Received: from AMSPR05MB065.eurprd05.prod.outlook.com (10.242.89.142) by
    DBXPR05MB079.eurprd05.prod.outlook.com (10.242.138.22) with Microsoft SMTP
    Server (TLS) id 15.1.93.16 via Mailbox Transport; Thu, 5 Mar 2015 16:16:31
    +0000
    Received: from DBXPR05CA0014.eurprd05.prod.outlook.com (10.255.178.14) by
    AMSPR05MB065.eurprd05.prod.outlook.com (10.242.89.142) with Microsoft SMTP
    Server (TLS) id 15.1.99.14; Thu, 5 Mar 2015 16:16:30 +0000
    Received: from DB3FFO11FD028.protection.gbl (2a01:111:f400:7e04::145) by
    DBXPR05CA0014.outlook.office365.com (2a01:111:e400:9434::14) with Microsoft
    SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Thu, 5 Mar 2015
    16:16:29 +0000
    Received: from emea01-am1-obe.outbound.protection.outlook.com (157.56.112.128)
    by DB3FFO11FD028.mail.protection.outlook.com (10.47.217.59) with Microsoft
    SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Thu, 5 Mar 2015
    16:16:28 +0000
    Received: from DB4PR04CA0010.eurprd04.prod.outlook.com (25.160.41.20) by
    DB3PR04MB236.eurprd04.prod.outlook.com (10.242.130.24) with Microsoft SMTP
    Server (TLS) id 15.1.99.14; Thu, 5 Mar 2015 16:16:26 +0000
    Received: from DB3FFO11FD040.protection.gbl (2a01:111:f400:7e04::184) by
    DB4PR04CA0010.outlook.office365.com (2a01:111:e400:9852::20) with Microsoft
    SMTP Server (TLS) id 15.1.106.15 via Frontend Transport; Thu, 5 Mar 2015
    16:16:26 +0000
    Received: from mail.localdomainhere (<IP OF OUR ON-PREM SERVER GOES HERE>) by
    DB3FFO11FD040.mail.protection.outlook.com (10.47.217.71) with Microsoft SMTP
    Server (TLS) id 15.1.99.6 via Frontend Transport; Thu, 5 Mar 2015 16:16:25
    +0000
    Received: from INT-EX-01.localdomainhere (192.168.142.20) by
    INT-EX-01.localdomainhere (192.168.142.20) with Microsoft SMTP Server (TLS) id
    15.0.913.22; Thu, 5 Mar 2015 16:15:55 +0000
    Received: from INT-EX-01.localdomainhere ([fe80::aca4:88cf:3eaf:57dc]) by
    INT-EX-01.localdomainhere ([fe80::aca4:88cf:3eaf:57dc%12]) with mapi id
    15.00.0913.011; Thu, 5 Mar 2015 16:15:55 +0000
    From: Jake Ives <[email protected]>
    To: Jake Ives <[email protected]>
    Subject: Test01
    Thread-Topic: Test01
    Thread-Index: AdBXX6dyI5u99OGoSKmXroKKyMA3Tg==
    Date: Thu, 5 Mar 2015 16:15:54 +0000
    Message-ID: <[email protected]>
    Accept-Language: en-US, en-GB
    Content-Language: en-US
    X-MS-Has-Attach: yes
    X-MS-TNEF-Correlator:
    x-originating-ip: [192.168.142.73]
    Content-Type: multipart/related;
                boundary="_004_081f834d85b7436193fa887613b9dac7INTEX01localdomainhere_";
                type="multipart/alternative"
    MIME-Version: 1.0
    Return-Path:
    [email protected]
    X-EOPAttributedMessage: 1
    Received-SPF: Pass (protection.outlook.com: domain of domain.com
    designates <IP OF ONPREM SERVER HERE> as permitted sender)
    receiver=protection.outlook.com; client-ip=<IP OF OUR ON-PREM SERVER GOES HERE;
    helo=mail.domain.co.uk;
    Authentication-Results: spf=pass (sender IP is <IP OF OUR ON-PREM SERVER GOES HERE>)
    [email protected]; ives.gb.net; dkim=none (message not
    signed) header.d=none;ives.gb.net; dkim=none (message not signed)
    header.d=none;ives.gb.net; dmarc=none action=none header.from=domain.com;
    X-Forefront-Antispam-Report-Untrusted: CIP:<IP OF ON PREM SERVER HERE>;CTRY:GB;IPV:NLI;EFV:NLI;BMV:0;SFV:NSPM;SFS:(10019020)(438002)(189002)(199003)(71364002)(87936001)(2656002)(98436002)(92726002)(102836002)(108616004)(19625215002)(19618635001)(512954002)(92566002)(229853001)(107886001)(66926002)(18206015028)(84326002)(16796002)(19300405004)(450100001)(19580395003)(2900100001)(77156002)(15974865002)(62966003)(5250100002)(5310100001)(99936001)(15395725005)(16236675004)(110136001)(17760045003)(67866002)(86362001)(19617315012)(19627595001)(15975445007)(19580405001)(54356999)(22756005)(50986999)(6806004)(46102003)(74482002)(106466001)(33646002)(7099025)(24736002)(15669805003);DIR:OUT;SFP:1102;SCL:1;SRVR:DB3PR04MB236;H:mail.domain.co.uk;FPR:;SPF:Pass;MLV:ovrnspm;MX:1;A:1;PTR:mail.domain.co.uk;LANG:en;
    X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB236;UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR05MB065;
    X-Microsoft-Antispam-PRVS: <[email protected]outlook.com>
    X-Exchange-Antispam-Report-Test: UriScan:;UriScan:;
    X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5001007)(5005006);SRVR:DB3PR04MB236;BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB236;BCL:0;PCL:0;RULEID:(601004);SRVR:AMSPR05MB065;BCL:0;PCL:0;RULEID:;SRVR:AMSPR05MB065;
    X-Forefront-PRVS: 05066DEDBB
    X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB236
    X-MS-Exchange-Organization-MessageDirectionality: Incoming
    Received-SPF: Fail (protection.outlook.com: domain of domain.com does not
    designate 157.56.112.128 as permitted sender)
    receiver=protection.outlook.com; client-ip=157.56.112.128;
    helo=emea01-am1-obe.outbound.protection.outlook.com;
    Authentication-Results: spf=fail (sender IP is 157.56.112.128)
    [email protected];
    X-Forefront-Antispam-Report: CIP:157.56.112.128;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(339900001)(489007)(189002)(71364002)(199003)(102836002)(92726002)(15975445007)(92566002)(17760045003)(62966003)(106466001)(15395725005)(16236675004)(77156002)(110136001)(107886001)(450100001)(5310100001)(229853001)(22756005)(98436002)(2900100001)(5250100002)(19625215002)(66926002)(99936001)(33646002)(15974865002)(19617315012)(19627595001)(67866002)(54356999)(108616004)(19300405004)(19618635001)(87836001)(2656002)(18206015028)(85426001)(512954002)(86362001)(6806004)(46102003)(74482002)(84326002)(19580395003)(50986999)(19580405001)(7099025)(24736002)(15669805003);DIR:INB;SFP:;SCL:1;SRVR:AMSPR05MB065;H:emea01-am1-obe.outbound.protection.outlook.com;FPR:;SPF:Fail;MLV:ovrnspm;MX:1;A:1;PTR:mail-am1on0128.outbound.protection.outlook.com;LANG:en;
    X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB3FFO11FD028.protection.gbl
    X-MS-Exchange-Transport-CrossTenantHeadersPromoted: DB3FFO11FD028.protection.gbl
    X-MS-Exchange-Organization-Network-Message-Id: 927151e3-02c4-4c46-5539-08d22576df82
    X-MS-Exchange-Organization-AVStamp-Service: 1.0
    X-MS-Exchange-Organization-SCL: 1
    X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2015 16:16:28.9728
    (UTC)
    X-MS-Exchange-CrossTenant-Id: cd52bfe2-da2e-446d-b8f1-e78db861d489
    X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bfa61dad-1543-4f3b-8075-03498e9f4fcb;Ip=[IP OF ON PREM SERVER HERE]
    X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
    X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR05MB065
    X-MS-Exchange-Organization-AuthSource: DB3FFO11FD028.protection.gbl
    X-MS-Exchange-Organization-AuthAs: Anonymous
    X-MS-Exchange-Transport-EndToEndLatency: 00:00:03.5565465

    MX records are not set to office 365, the MX is pointing directly to the on-prem exchange server. 
    The problem is; Office 365 Mail Delivery Trace is displaying mail we've sent via our On-Prem server - We are having trouble understanding why this is happening.
    To clarify, the message tracer in Office 365 is displaying outbound mail (Which for example, a user has sent out from their outlook) BUT only outbound mail which is being sent to other office 365 users.
    We do not have mail on office 365, only on-premise hence the reason why we are flabbergasted to why the mail we are sending out would be displaying on the office 365 message tracer.
    To further clarify, we are only seeing addresses in the office 365 message trace which belong to recipients whom use office 365 for their mail.
    Hope this makes sense.
    getting messy O365 users to another O365 you mean?
    You mentioned if they send email using their MS Outlook Client.
    I'd suggest you to send another email to the same recipient but using OWA
    There may have been an office 365 connector in Outlook.
    Where Technology Meets Talent

  • How to return "HTTP/1.0 401 Authorization Required" from OSB's Message Flow

    How can I return "HTTP/1.0 401 Authorization Required" header from OSB's Message Flow?
    Using of "HTTP Transport -> Authentification" is not possible, because I need flow condition. Transports Headers activity from design palette doesn't allow to send such headers.
    Practical usage: request for kerberos ticket by sending two headers: 401 and WWW-Authenticate: Negotiate...

    Can you briefly expand the use case for better understanding?
    HTTP Client---> Hand Shakes or what ever ----> HTTP Proxy (OSB )---> Pipeline----
    Philosophy behind pipeline is that it is designed to work on the request. Correct me if I'm wrong.
    What you are asking is ability to control the hand shake either in Pipeline or some way during proxy configuration. Unfortunately there is no configuration that is exposed for HTTP proxies in OSB to control that behavior.
    Manoj

  • XI Message flow

    I am trying to integrate a r/3 system with XI, can someone point me to possible data flow diagrams.
    What can be a possible scenario here...?
    Can someone also point me to the message flow within IR and ID for the above scenario..
    Regards
    Ravi

    Hi,
    Pipeline steps for XI Message flow steps , This might help you to understand
    Pipeline :
    When a source message reaches the Integration server
    the messages under goes this
    a) Receiver Determination:
    This steps determines the system that participates in the exchange of the message.
    b) Interface Detremination:
    For each receiver determine which interface will should receieve the message.
    c) Message Split:
    If more than one receievers are found, XI will instantiate new message for each receiver.
    d) Message Mapping:
    Mapping to transform the source message to destination message format.
    e) Technical Routing:
    Bind a specific destination and protocol to the message.
    f) Call outbound Adapter:
    Send the transformed message to the adapter or a proxy.
    Regards
    Agasthuri Doss

  • Proxy communication message flow,

    Hi all,
       Can any body help me out  in understanding the message flow in Proxy communication and how is it different from the flow that involves Techical Adapters?.How the mesage Id will  be created in Proxies for messages? .Lets suppose The scenario is  Proxy (ABAP) to Proxy (ABAP).Please explain in this perspective.Any good links,blogs ,Docs with useful explanation will be helpful to me .
    Thanks,
    Amar.

    Hi Amar,
    Hi,
    Please refer to these Blogs...
    Communication between SAP System & Webservice Using Proxies
    /people/siva.maranani/blog/2005/05/23/communication-between-sap-system-webservice-using-proxies
    ABAP Proxies in XI(Client Proxy)
    /people/ravikumar.allampallam/blog/2005/03/14/abap-proxies-in-xiclient-proxy
    ABAP Server Proxies
    /people/siva.maranani/blog/2005/04/03/abap-server-proxies
    Regards
    Mahesh

  • Message Flow in Integration Engine

    Dear Friends,
    Kindly can someody share  how the message is flowing in Intergration engine after the message taken from Adapter engine.
    If you have any block diagram it will be helpful for me

    Hi Karthik,
    There are 6 stpes for the message processing thats only called
    PIPELINE Steps.
    what are all the steps involved in the Pipeline processing.
    Sender Adapter picks up the file from the file system, converts it to XML and places it in the payload of an XI-SOAP message. Then it posts this message to the Integration Server pipeline via http(s).
    XI pipeline steps are:-
    ->Sender Agreement
    ->Receiver Determination
    ->Interface Determination
    ->Interface Mapping
    ->Receiver Agreement.
    When a source message reaches the Integration server, it performs 6 steps before the message reaches the destination. The steps are:
    1) Receiver Determination: This steps determines the system that participates in the exchange of the message.
    2) Interface Determination: For each receiver determine which interface will should receiver the message.
    3) Message Split: If more than one receivers are found, Xi will instantiate new message for each receiver.
    4) Message Mapping: Mapping to transform the source message to destination message format.
    5) Technical Routing: Bind a specific destination and protocol to the message.
    6) Call outbound Adapter: Send the transformed message to the adapter or a proxy.
    One can examine these steps in Runtime Workbench using the Transaction: SXMB_MONI.
    message flow in XI
    The life cycle of the message is explained in detail by taking an example scenario. The file is picked up by the Sender File adapter and the data is inserted into DB table by Receiver DB Adapter.
           The adapter engine uses the messaging system to log the messages at every stage. This log is called the Audit Log. The audit log can be viewed from the runtime work bench (RWB) to look into the details of the lifecycle of the message. During our journey we will also have a look at the messages that are logged at different stages.
    Note: This article is targeted for the newbieu2019s who want to understand the message flow in Adapter Engine. So the insight into the message lifecycle is provided here by taking only the Technical adapters (File/ JDBC/ JMS/ Mail) into consideration. It doesnu2019t delve into the lifecycle of the messages that have reached XI Adapter Engine using RNIF/ BC/ CIDX adapters.
    ONWARD JOURNEY:
    Fig1. Message flow from Adapter Engine to Integration Server
    1.     For the message to be picked up by the communication channel, the channel should be associated with a sender agreement. Here creation of a communication channel doesnu2019t ensure the message to be polled and picked up by the adapter. The message reaches the adapter in its native message format. As the communication in SAP XI happens in XI message format, a module inside the adapter converts the message in native format into XI message format.
    2.     During this process, a message ID is generated for the message. To build the XI header (sender agreement details like the sender system, sender message interface and the interface namespace) the details are fetched by performing a CPA lookup(collaboration-partner-agreement are the configuration object details that have been created using the configuration time. The details are updated into the runtime cache when you activate the Configuration objects in Integration builder u2013Configuration time. This cache is referred to as CPA cache).
    3.     This message is then sent to module processor for further processing. During the process of sending the message to module processor, the message u201CApplication attempting to send an XI message asynchronously using connection AFWu201D is logged.
    4.     The module processor performs steps like structure conversion, communication channel specific conversions (that have been specified in the u201Cmodule tabu201D of the adapter channel). These conversion modules are executed in the same sequence as mention in the communication channel.
    5.     After the successful execution of the conversion modules, the appropriate module (call SAP adapter module) of the module processor is called which will send this message for persistent storage. This message is put into the Send Queue of the messaging system for further processing. Messages like u201CMessage trying to put into the send Queueu201D and u201CMessage successfully put into the queueu201D are logged during this process. A confirmation message (success/ failure) is sent back to the sender application at this stage. This confirmation message is used by the channel to perform various steps like deleting the file that has a processing mode as delete.
    6.     The message that has been put in the Send Queue has to be picked up and sent to the Integration Engine. The Adapter Engine and XI Integration server use XI Adapter for internal communication purposes. So the XI Adapter picks up message from the send queue and parses the XI message. In this process, the status of the message is set to DLNG and. Messages like u201CThe message was successfully retrieved from the send queue and message status set to DLNGu201Dare logged.
    7.     The XI adapter performs a SLD look up (System landscape Directory) to find the Integration server with which the Adapter framework has register itself.
    8.     On successful SLD look up, the message is sent via HTTP to the XI IS pipeline, using the pipeline URL (http://hostname:abap-httpport/sap/xi/engine?type=entry). . If this is successful, a message u201CThe message was successfully transmitted to endpoint http://hostname:8000/sap/xi/engine?type=entry using connection AFWu201D is logged and the message statues is set to DLVD means message has been successfully delivered to the endpoint( XI IS in this case)
    Fig2. Audit Log of message during onward journey
    RETURN JOURNEY:
    The return journey commences when the IS has successfully processed the message and delivers it to the Messaging system using the URL u201Chttp://hostname:50000/MessagingSystem/receive/AFW/XIu201D
    br>
    Fig3. Message flow from Integration Server to Adapter Engine
    1.     When the Integration Server (XI IS) finishes processing of the pipeline steps (like receiver determination, interface determination and interface mapping), the message has to be delivered to the required Receiving system. So the XI Integration server will send the message to the messaging system of the Adapter Engine (AE) using the mentioned above. Once the message is successfully received by messaging system, the message u201CThe message was successfully received by the messaging system. Profile: XI URL: http://hostname:50000/MessagingSystem/receive/AFW/XIu201D is logged.
    2.     As discussed Integration server and Adapter Engine use XI adapter for internal communication purposes. So the XI message that has been received by the messaging system URL is parsed by the XI Adapteru2019s protocol handler.
    3.     The XI message is put into the receive queue and persisted. During this stage messages like u201CUsing connection AFW. Trying to put the message into the request queue; Message successfully put into the queue.u201D are logged.
    4.     The XI messages that are put in the receive queue are retrieved by an application (Worker thread) and are sent to AFWListenerBean. AFWListenerBean is a module (an EJB) in Adapter Engine that is capable of parsing the XI message. On successful receive of the XI message by the AFWListenerBean, messages like u201CThe message was successfully retrieved from the request queue.u201D are logged and the status of the XI message is set to DLNG.
    5.     The AFWListenerBean reads the receiver agreement and the corresponding channel from the XI header to determine the appropriate adapter. In this stage the adapter channel is logged in the audit log. u201CDelivering to channel: XYZ_Channelu201D
    6.     The message is forwarded to the module processor where additional steps like structure conversions and extra modules specified in the adapter are performed.
    7.     The exit module is called and the message is sent to the appropriate adapter (DB Adapter in this case). The format conversion will be executed within the specific adapter and sent to the Receiving system (DB in this case) using the channel that has been determined by the AFWListenerBean and the required action is reformed (select statement is performed in this case). On successful processing of the message the status is set to DLVD.

Maybe you are looking for