Japanese Data Corruption in SOAP Response

Hello,
I'm in an environment where I need to pass Japanese data through a SOAP service using an Element. When I return
the Element in response tor my SOAP request I'm receiving corrupted data in the XML. The XML data of the Element on
the server side looks perfect. Does anyone have any suggestions what might be wrong?
I'm using Oracle SOAP from iAS v1.0.2.2.
My client code looks like this:
Call call = new Call();
call.setTargetObjectURI( serviceId );
call.setMethodName( "select" );
call.setEncodingStyleURI( Constants.NS_URI_LITERAL_XML );
Vector params = new Vector();
params.addElement( new Parameter( "max",
int.class,
new Integer( 50 ),
Constants.NS_URI_SOAP_ENC ) );
Any help would be greatly appreciated! Thanks!
-ann

Hello,
Still no luck, but I did try to send the XML as a string. The results were greatly improved, but still not right. This
client code looks like this:
Locale.setDefault(new Locale("ja","JP"));
Call call = new Call();
call.setTargetObjectURI( serviceId );
call.setMethodName( "select" );
call.setEncodingStyleURI( Constants.NS_URI_SOAP_ENC );
Vector params = new Vector();
// Specify to return a maximum of 50 records
params.addElement( new Parameter( "max",
int.class,
new Integer( 50 ),
null ) );
The resulting Japanese data has the correct characters, but includes extraneous ones as well.
Can anyone help me with this?
Thanks!
-ann

Similar Messages

  • Data from SOAP response not getting into Flex object

    I'm trying to get data from an ALM application we use(Collabnet TeamForge) using a SOAP webservice, and am running into a problem.  I should mention that I am new to both Flex, and webservices.
    I used the "Import Web Services" option in Flex Builder 3, and had it generate code for all operations in the WSDL.  Some of them work just fine.  However, there are several where the data from the SOAP response does not get into the Flex object. The senario that doesn't work is when the response contains a data type that extends another datatype.  In TeamForge, they have a type called TrackerSoapRow.  It extends FolderSoapRow, adding 3 fields.  The problem seems to be that in the response from TeamForge, the 3 fields defined in TrackerSoapRow are in the middle of the fields defined in FolderSoapRow.  I've debugged into it, and the problem occures in mx.rpc.xml.XMLDecoder.getApplicableValues( starting at line 2204 of XMLDecoded.as).  As I read the code, the only way a match can be found is if the fields in the response are in the exact same order as in the definintion.  When its processing the extended data type(  by a call to XMLDecoder.decodeComplexExtension ) at some point, one of the derived type's fields is encountered, and the process stops.
    I have called the service using soapui and verified that all the data I expect is in the response.
    As I mentioned, I'm new to web services.  So, I suppose its possible that the format of the data being returned from TeamForge is incorrect.  That they are not supposed to intermingle base and derived fields.  If thats the case, then I need to report this as a bug to Collabnet.
    All help is appreciated.
    Marc Robertson

    Not knowing any of the details about how you call a web service from OAF myself - I'd suggest you post on the proper forum for OA Framework questions: {forum:id=210}
    John

  • Data Headers in SOAP adapter Response

    Hi there,
    I have a working SOAP adapter on Xi 2.0, which accepts incoming requests from SOAP clients, it "transforms" these requests into RFC calls which in turn calls BAPI'S in R/3.
    The BIG issue is that Xi (the SOAP adapter) sets and sends a set of headers into the response back to the SOAP client. For security and performance reasons, you dont want the system to send those headers over the net to the SOAP client.
    Does anyone knows how to setup Xi in order to suppress these headers in the SOAP response?
    PS: Below an example of the headers in the SOAP envelope.
    <SOAP:Envelope xmlns:SOAP='http://schemas.xmlsoap.org/soap/envelope/'>
    <SOAP:Header><sap:MessageHeader xmlns:sap='http://sap.com/exchange/MessageFormat' version='1.0'>.......
    <Host>xxxx</Host>
    <Sysid/>
    <Sysnr>00</Sysnr>
    <Mandt>200</Mandt>
    <Dest/>
    <Userid>XI_USER</Userid>
    <Passwd>xxxx</Passwd>

    If I want to set the content in the SOAP header when the client in SAP XI how would I do that?
    I cannot see SOAP Header in XI MONI.
    Please advice. I want to add to the contents of SOAP Header created by XI SOAP Receiver Channel.
    Thanks
    Ashish

  • Error:SOAP: response message contains an error XIAdapter/PARSING/ADAPTER.SOAP_EXCEPTION - soap fault: Server was unable to read request. --- There is an error in XML document (1, 447). --- Input string was not in a correct format.

    Hi All,
        We have a scenario of FTP-->PI---> Webservice.  While triggering the data in the FTP, it is failing in the PI with the below error
    SOAP: response message contains an error XIAdapter/PARSING/ADAPTER.SOAP_EXCEPTION - soap fault: Server was unable to read request. ---> There is an error in XML document (1, 447). ---> Input string was not in a correct format.
    Can you please help?

    Hi Raja- It seems to be a data quality issue.
    Check for the value @ 1447 position in the xml message that you are trying to send to web service..
    may be a date filed/decimal value which is not in expected format.

  • SOAP: response message contains an error XIAdapter/HTTP/ADAPTER.HTTP_EXCEPT

    Hi there,
    I am trying to publish a file from SAP as web service using XI and SOAP Adapter.
    I am using ABAP proxy to get the data into XI.
    Designing and Configuration in XI has no problems because when i use File adapter the data is trasmitted to FTP server.
    But when I used SOAP Reciever adapter I am getting following error in RWB
    Delivery of the message to the application using connection SOAP_http://sap.com/xi/XI/System failed, due to: com.sap.aii.af.ra.ms.api.RecoverableException: SOAP: response message contains an error XIAdapter/HTTP/ADAPTER.HTTP_EXCEPTION - HTTP 500 Error during parsing of SOAP header.
    <b>Scenario</b>: SAP ABAP Proxy -> XI -> WebService. Asynchronous.
    <b>SOAP</b> Receiver adaptor.
    <b>Target URL</b> http://<host>:<port number >/sap/xi/engine?type=entry&version=3.0&Sender.Service=SAPDC2653&Interface=urn:bzttest:00:hsa:test%5EOB_MI_BZT_TEST&QualityOfService=ExactlyOnce
    Do not use SOAP Envelop is checked.
    <b>SOAP Action</b> http://sap.com/xi/WebService/soap1.1
    What i am missing here? How should I solve this problem?
    Any help is appreciated,
    Thx,
    Yogi

    Say there's a bapi/rfc that you want to call on an R/3 backend (e.g. 4.6c).  On it's own, the R/3 system cannot expose the rfc/bapi as a web service, but XI can.  So in this case, the scenario would be:
    WS client -> XI -> R/3
    When XI "exposes" a web service, it is exposing a service for a receiving system (in the above example, the R/3 system).  XI itself does not provide or contain the service implementation.  When XI exposes a web service, it is always done via the <b>sender</b> soap adapter (i.e. if soap adapter is used).   Receiver soap adapter is used to call or consume an actual web service from an external application.
    Regards,
    Jin

  • Soap response with envelope

    Hi
    My PI server is able to make a soap call to the SFDC ( webservice ) ...however the response that is received within PI
    has a SOAP envelope...and hence the response mapping is going in error....because the source data type in response mapping doesnot match with the soap response ( with envelope )
      <?xml version="1.0" encoding="UTF-8" ?>
    - <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:enterprise.soap.sforce.com">
    - <soapenv:Body>
    - <upsertResponse>
    - <result>
      <created>false</created>
      <id>a0UT0000004aeaMMAQ</id>
      <success>true</success>
      </result>
      </upsertResponse>
      </soapenv:Body>
      </soapenv:Envelope>
    how do i handle this

    Hi,
    I think there is an option while configuration of SOAP adapter, where you can define, not to keep SOAP envelop. Please check the option Conversion Parameters\Do Not Use SOAP Envelope and set it as per your requirement. That might solve the problem. Here is the link which can be helpful
    http://help.sap.com/saphelp_nw04/helpdata/en/29/5bd93f130f9215e10000000a155106/content.htm
    Alternatively you need a java mapping or XSLT mapping to remove the envelop.
    Here is the java mapping code to remove SOAP envelop
    import java.io.FileInputStream;
    import java.io.FileOutputStream;
    import java.io.InputStream;
    import java.io.OutputStream;
    import java.util.Map;
    import javax.xml.parsers.DocumentBuilder;
    import javax.xml.parsers.DocumentBuilderFactory;
    import javax.xml.transform.Transformer;
    import javax.xml.transform.TransformerFactory;
    import javax.xml.transform.dom.DOMSource;
    import javax.xml.transform.stream.StreamResult;
    import org.w3c.dom.Document;
    import org.w3c.dom.Element;
    import org.w3c.dom.Node;
    import org.w3c.dom.NodeList;
    import com.sap.aii.mapping.api.StreamTransformation;
    import com.sap.aii.mapping.api.StreamTransformationException;
    public class RemoveSoapEnvelop implements StreamTransformation{
    public void execute(InputStream in, OutputStream out)
    throws StreamTransformationException {
    try
         DocumentBuilderFactory factory=DocumentBuilderFactory.newInstance();
         DocumentBuilder builderel=factory.newDocumentBuilder();
         /*input document in form of XML*/
         Document docIn=builderel.parse(in);
         /*document after parsing*/
         Document docOut=builderel.newDocument();
         TransformerFactory tf=TransformerFactory.newInstance();
         Transformer transform=tf.newTransformer();
         Element root;
         Node p;
         NodeList l;
         int mm,n1;
         //if you need to include namespace use next two lines
         //root=docOut.createElement("ns0:upsertResponse");
         //root.setAttribute("xmlns:ns0","http://connectsystems.be/MAINFR/AccDocument");
         root=docOut.createElement("upsertResponse");
         p=docIn.getElementsByTagName("upsertResponse").item(0);
         l=p.getChildNodes();
         n1=l.getLength();
         for(mm=0;mm<n1;++mm)
              Node temp=docOut.importNode(l.item(mm),true);
              root.appendChild(temp);
         docOut.appendChild(root);
         transform.transform(new DOMSource(docOut), new StreamResult(out));
    catch(Exception e)
         e.printStackTrace();
    public void setParameter(Map arg0) {
    public static void main(String[] args) {
    try{
         RemoveSoapEnvelop genFormat=new RemoveSoapEnvelop();
         FileInputStream in=new FileInputStream("C:\\Apps\\my folder\\sdn\\sd2.xml");
         FileOutputStream out=new FileOutputStream("C:\\Apps\\my folder\\sdn\\removedEnvelop.xml");
         genFormat.execute(in,out);
    catch(Exception e)
    e.printStackTrace();
    input xml file sd2.xml
      <?xml version="1.0" encoding="UTF-8" ?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:enterprise.soap.sforce.com">
    <soapenv:Body>
    <upsertResponse>
    <result>
      <created>false</created>
      <id>a0UT0000004aeaMMAQ</id>
      <success>true</success>
      </result>
      </upsertResponse>
      </soapenv:Body>
      </soapenv:Envelope>
    Here is the output xml removedEnvelop.xml
      <?xml version="1.0" encoding="UTF-8" ?>
    <upsertResponse>
    <result>
      <created>false</created>
      <id>a0UT0000004aeaMMAQ</id>
      <success>true</success>
      </result>
      </upsertResponse>
    Helpful articles on java mapping for PI 7.1
    http://wiki.sdn.sap.com/wiki/display/XI/SampleJAVAMappingcodeusingPI7.1+API
    You can also try following XSLT mapping to get the same output as java mapping
    <xsl:stylesheet version="1.0"
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    exclude-result-prefixes="SOAP-ENV">
    <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />
    <xsl:template match="/">
    <xsl:for-each select="SOAP-ENV:Envelope/SOAP-ENV:Body">     
    <upsertResponse>
    <result>
         <xsl:variable name="var" select="normalize-space(.)"></xsl:variable>
         <xsl:variable name="tokenizedSample" select="tokenize($var,' ')"/>
        <created><xsl:value-of select="$tokenizedSample[1]"/></created>
        <id><xsl:value-of select="$tokenizedSample[2]"/></id>
        <success><xsl:value-of select="$tokenizedSample[3]"/></success>
    </result>
    </upsertResponse>
    </xsl:for-each>
    </xsl:template>
    </xsl:stylesheet>
    Other than these please refer to following links for further examples on the topic
    Remove SOAP-ENV tags from xml RECEIVER RESPONSE payload (XSL needed?)
    Remove SOAP Envelop using XSLT  mapping.
    Hope this helps your cause.
    regards
    Anupam

  • Missing tag in SOAP Response object

    Currently running WebLogic 8.1 SP2 (legacy system, unable to upgrade to newer versions).
    Looking at a SOAP Response from a Web Service call, it's notable that there are some missing tags in the response. When the same call is made through an RMI invocation, the data is there, so it appears that it's being set correctly. The obvious answer is that it's an XML serialization problem, but there are no errors in any log files and the Codec classes for a working class and non-working class look identical.
    Let me explain better
    We have essentially:
    Class foo {
    public int getID();
    public void setID(int);
    Class bar1 extends foo {
    //other stuff
    Class bar2 extends foo {
    //other stuff
    The Schema defines the ID field as minOccurs="1" (the default).
    The response coming from the server will look something like this:
    <foo>
    <bar1>
    <ID>TheID</ID>
    ...other stuff...
    </bar1>
    </foo>
    However, if the returned object is of the other type...
    <foo>
    <bar2>
    ...other stuff, but no ID...
    </bar2>
    </foo>
    The classes and service are being generated from a WSDL and XSD files, searching through the value and codec classes shows no fundamental difference between the implementation of the two subclasses, yet one shows the ID, and the other doesn't.
    Anyone have any idea where to look to start narrowing down the problem? This has us completely baffled.

    I guess I'll answer my own question since I've since been able to solve it in the hopes that it will someday help someone else.
    Short answer: There is a bug in WebLogic 8.1 SP2 which generates the isPropertySet(int index) method in the Codecs incorrectly for certain subclasses.
    Using the foo example from the original question
    class foo;
    class bar extends foo;
    class dot extends foo;
    If dot has additional properties, the Codec will be generated incorrectly. They should look like:
    <pre>
    protected boolean isPropertySet(Object my_obj, int idx) {
    if (idx < SUPERPROP_COUNT) return super.isPropertySet(my_obj,idx);
    idx -= SUPERPROP_COUNT;     
    Dot typed_obj = (Dot) my_obj;
    switch(idx) {
    case 0:
    return typed_obj._isSetAdditionalProperty();
    </pre>
    ...etc
    What it actually does look like is...
    <pre>
    protected boolean isPropertySet(Object my_obj, int idx) {
    Dot typed_obj = (Dot) my_obj;
    switch(idx) {
    case 0:
    return typed_obj._isSetAdditionalProperty();
    </pre>
    ...etc
    so attempting to get the eariler properties of the super class from an instance of the sub class returns erratic results depending on whether properties of the subclass were set.
    Anyway, this was fixed in SP3 or 4, and there was a patch available to fix it in SP2 as well. Good luck if anyone else happens to run into this problem.

  • Problem in displaying dynamic japanese data in JSP

    Hi all,
    I am trying to display japanese data (address) fetched from RDBMS database but only ???????? getting displayed. First the data is fetched from database then populated in xml. From xml databean is created .
    Steps taken
    I have put chartset =shift-jis in jsp response header .
    I made sure the encoding for XML file is UTF-8 for parsing. I am using documentbuilder object for parsing for xml.
    I am not sure what needs to be done to display japnese text properly.
    I appreciate if i get solution as i am struck with this for long time
    Regards,
    prasad

    Your JSP pages need to contain a JSP directive that specifices the encoding for the pages (one that supports Japanese).
    I use:
    <%@ page contentType="text/html;charset=UTF-8" %>
    You could also use:
    <%@ page contentType="text/html;charset=SHIFT-JIS" %>
    When you view with your browser also remember to set the page encdoing and ensure your OS has the proper fonts installed.

  • Weblogic throwing "null SOAP element Exception" in multi-part SOAP response

    Hi All,
    I'm using weblogic 10. My application is a webservice client generated using '*clientgen*', which is running on weblogic, and
    is invoking a remotely hosted webservice ( Remotely hoseted webservice may not be running on weblogic).
    I've the wsdl file of remotely hosted webservice.
    Now the problem is with WSDL file (I suppose), have a look at this.
    *&lt;message name="m1"&gt;*
    *&lt;part name="body" element="tns:GetCompanyInfo"/&gt;*
    *&lt;/message&gt;*
    *&lt;message name="m2"&gt;*
    *&lt;part name="body" element="tns:GetCompanyInfoResult"/&gt;*
    *&lt;part name="docs" type="xsd:AnyComplexType"/&gt; ------&gt; assume all elements inside this complex type can be nil or minOccurs set to '0'*
    *&lt;part name="logo" type="xsd:AnyOtherComplexType"/&gt; ------&gt; assume all elements inside this complex type can be nil or minOccurs set to '0'*
    *&lt;/message&gt;*
    &lt;portType name="pt1"&gt;
    &lt;operation name="GetCompanyInfo"&gt;
    &lt;input message="m1"/&gt;
    *&lt;output message="m2"/&gt; -----&gt; multi part message.*
    &lt;/operation&gt;
    &lt;/portType&gt;
    Now here is sample message for the request(I've composed this message for this question):
    &lt;soap:Envelope&gt; MESSAGE1
    &lt;soap:header/&gt;
    &lt;soap:body&gt;
    &lt;tns:m2&gt;
    &lt;tns:GetCompanyInfoResult&gt;
    Blah Blah....
    &lt;/tns:GetCompanyInfoResult&gt;
    &lt;tns:docs&gt;
    Blah Blah....
    &lt;/tns:docs&gt; Assume no data for 'logo', so it's not returned. Since all its elements can be nillable.
    &lt;tns:m2&gt;
    &lt;/soap:body&gt;
    &lt;/soap:Envelope&gt;
    First of all, is this SOAP response is valid? I'm not sure about *'message' and 'parts' in SOAP*, but according to XML schema standards it's invalid.
    Because, according to *'message' m2, 'logo' is missing*, eventhough all it's elements are nillable in such case there should be *&lt;logo/&gt;* at the end.
    I mean valid message should be like below
    &lt;soap:Envelope&gt; '*MESSAGE2*'
    &lt;soap:header/&gt;
    &lt;soap:body&gt;
    &lt;tns:m2&gt;
    &lt;tns:GetCompanyInfoResult&gt;
    Blah Blah....
    &lt;/tns:GetCompanyInfoResult&gt;
    &lt;tns:docs&gt;
    Blah Blah....
    &lt;/tns:docs&gt;
    *&lt;tns:logo/&gt; ------------------&gt; here is the change compared to above message. empty element.*
    &lt;tns:m2&gt;
    &lt;/soap:body&gt;
    &lt;/soap:Envelope&gt;
    Now the concerns are :
    (1) Which is a valid response? Message1 or Message2
    (2) If message1 is valid then why is weblogic throwing an exception 'null SOAP element', I suppose this is due to missing 'logo' element.
    (To confirm this I've used tcpmonitor and found message1 as response but weblogic is still throwing 'null SOAP Element' exception,
    which confirms it needs 'logo' as well, I suppose &lt;logo/&gt; at least). Is there any workaround for this in weblogic for multi-part messages?
    (3) If message1 is invalid according to SOAP standards then You've answered my question. ---&gt; I need to talk to the webservice provider in this case.....
    Thanks in advance...

    Message 1 is not Basic Profile 1.1 compliant. It is specified by BP1.1 in section 4.4.1(http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Bindings_and_Parts) that when a wsdl:part element is defined using the type attribute, the serialization of that part in a message is equivalent to an implicit (XML Schema) qualification of a minOccurs attribute with the value "1", a maxOccurs attribute with the value "1" and a nillable attribute with the value "false".

  • How to attach files in soap response?

    IS there any way to attach a file in soap response? how to do that??:|

    Probably MTOM is what you need:
    http://edocs.bea.com/wls/docs100/webserv/jws.html#mtom
    But this is apparently not doable with ALSB (it would be supported just with regular web services):
    http://forums.bea.com/thread.jspa?threadID=300002302
    Note the file naming would need to be done by the SOAP client:
    http://www.jroller.com/gmazza/date/20071102 (Look at Steps #6 and #11 and Note # 7)
    HTH,
    Glen

  • SOAP Response cannot be decoded.

    Hello Everybody,
    I created a simple web service in asp.net using the c# sharp language. The web service extracts data from an MS SQL Database, translates that data in to xml, assigns the xml to a string varible and returns  the string varible to what ever called the service. I know the web service works becuase if you call it in a web browser at the following address http://www.jmmortimer.com/dataaccess/sqlhelper.asmx?wsdl, it will show you the xml that represents web service. Plus, I tested it by calling it in an asp.net application. However when I call it from a Flex 3 application it gives me the following error message. SOAP Response cannot be decoded. Raw response: " faultCode="DecodingError" faultDetail="null" The code that I have in Flex 3 is below. If anyone knows how to solve this problem, please let me know. Thanks in advance.
    <?xml version="1.0" encoding="utf-8"?>
    <mx:Application 
    xmlns:mx=http://www.adobe.com/2006/mxml layout="absolute">
    <mx:Script>
    <![CDATA[
    import mx.rpc.soap.LoadEvent;
    import mx.rpc.events.ResultEvent;
    private function getData(evt:LoadEvent):void
    var connString:String = "Data Source=Family\SQLExpress;Initial Catalog=SDJames;User ID=sa;Password=Password1";
    var storedProc:String = "GetAuxiliaries";
    myService.GetDataTable(connString, storedProc)
    private function resultHandler(evt:ResultEvent):void
    test.text = String(evt.result);
    ]]> 
    </mx:Script>
    <mx:WebService id="myService" wsdl="http://jmmortimer.com/dataaccess/sqlhelper.asmx?WSDL"
    load="getData(event)" result="resultHandler(event)" />
    <mx:TextArea id="test" x="10" y="10" width="452" height="348"/>
    </mx:Application>

    Hello Again Everybody,
    I have found the answer to my problem. The Problem was that I had the wrong value assigned the variable "connString" insted of  "Data Source=Family\SQLExpress;Initial Catalog=SDJames;User ID=sa;Password=Password1", it should have been "Data Source=Family\\SQLExpress;Initial Catalog=SDJames;User ID=sa;Password=Password1". Don't you just hate how just  messing up with one character can mess up you entire application. Thanks to everybody who took time to look over my problem.
    God Bless

  • Error Reading Soap Response

    Hi,
    We are having a problem reading Soap Response:
    Scenario: From XI/PI we are calling a webservice with Synchronous
    message with WS-Security including Authentication, Signature, TimeStamp
    and Encryption using SOAP Receiver Adapter. We are able to send the
    request successfully and also the webServer is able to understand the
    request and sending the response back. The problem is the PI is unable
    to read the response and giving a below error:
    com.sap.aii.af.ra.ms.api.DeliveryException: expecting end tag:
    Transform, but found
    InclusiveNamespaces at state 1
    We tested successfully end-end with NON-Secured sites with out WS-
    Security.
    Please let me know if you have seen this error or any thoughts.
    Thanks,
    Laxman
    This is the actual Request Message:
      <?xml version="1.0" encoding="UTF-8" ?>
              <ns0:getUser xmlns:ns0="http://csa -namespace:8090/ddsssaws/IdentityManagementService">
      <string>XYZ123</string>
      </ns0:getUser>
    Also we extracted raw traffic using TCPMon:
    Below is the raw-traffic of SOAP adapter (used TCPGateway to capture the traffic)
    Request:
    POST /edsssaws/IdentityManagement HTTP/1.0
    Accept: /
    Host: 999.97.19.45:9999
    User-Agent: SAP-Messaging-com.sap.aii.messaging/1.0505
    Content-ID: <soap-1f3af770018111ddc0d300144f2515b0Atsap.com>
    Content-Disposition: attachment;filename="soap-1f3af770018111ddc0d300144f2515b0Atsap.com.xml"
    Content-Type: text/xml; charset=utf-8
    Content-Description: SOAP
    Content-Length: 5530
    SOAPACTION:
    <SOAP:Envelope xmlns:SOAP='http://schemas.xmlsoap.org/soap/envelope/'><SOAP:Header><wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' SOAP:mustUnderstand='1'><wsse:BinarySecurityToken xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' wsu:Id='sap-9' ValueType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3' EncodingType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary'>MIIFFTCCBH6gAwIBAgIKZptrmQABAAALBTANBgkqhkiG9w0BAQUFADByMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDZWRzMRQwEgYKCZImiZPyLGQBGRYEY29ycDEUMBIGCgmSJomT8ixkARkWBGFtZXIxGjAYBgNVBAMTEUVEUyBFbnRlcnByaXNlQ0ExMB4XDTA4MDQwMTIxMjMyN1oXDTEwMDQwMTIxMjMyN1owIjELMAkGA1UEBhMCVVMxEzARBgNVBAMTCklUQVBJTlRERVYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALjKvScjIEmp5Q1X3/gfR0WZO22KiEAOAx9kM0q3kpT/0dk2ZVit5YCBT4Zkt6Tttyh21xmnCcVgcRo0YOxXcXrLq25HRsSbxY3Zu37qq4tqExX5gQCtfR1pRjRrhQfDPmPGzFOrTzSjxJ5BH49p3KZcUhj7KpWQEakDBvJAgMBAAGjggMAMIIC/DAdBgNVHQ4EFgQUadHS0gj0CBQymaNnAlGJphSCB/YwHwYDVR0jBBgwFoAULNVTI/CtjM0k4MlzJLuQI4tVUy8wggEaBgNVHR8EggERMIIBDTCCAQmgggEFoIIBAYaBxWxkYXA6Ly8vQ049RURTJTIwRW50ZXJwcmlzZUNBMSgxKSxDTj11c3Bsc3NjYTAwMixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JwLERDPWVkcyxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hjdodHRwOi8vd3d3LmVkcy5jb20vY3J0cmV2bHN0L0VEUyUyMEVudGVycHJpc2VDQTEoMSkuY3JsMIIBDwYIKwYBBQUHAQEEggEBMIHMIG2BggrBgEFBQcwAoaBqWxkYXA6Ly8vQ049RURTJTIwRW50ZXJwcmlzZUNBMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1jb3JwLERDPWVkcyxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwQwYIKwYBBQUHMAKGN2h0dHA6Ly93d3cuZWRzLmNvbS9jcnRyZXZsc3QvRURTJTIwRW50ZXJwcmlzZUNBMSgxKS5jcnQwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBLAwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIh4qV4WN/hPFkRuHwclug63SWS2GpOIihPT8LwIBZAIBBDATBgNVHSUEDDAKBggrBgEFBQcDATAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4GBAGzyuh56APinQtmE9oWsT8NHcQqMASHZnN26RAofnxuIUH1VyBK2CGyiiDnCS0cDIGBl45sqOO8uRClE7CngeZEAV9JL5bhpUF6rywmFKvqe5FyqnrScczeaODV0g9sO4vUrwdGlReA5ncvtSN/u82MWDqtHAHBfpYQxZUrW</wsse:BinarySecurityToken><wsu:Timestamp xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' wsu:Id='wsu-targetID-1f10b320-0181-11dd-aebd-00144f2515b0'><wsu:Created ValueType='xsd:dateTime'>2008-04-03T13:23:17Z</wsu:Created><wsu:Expires ValueType='xsd:dateTime'>2008-04-03T13:25:17Z</wsu:Expires></wsu:Timestamp><xenc:EncryptedKey xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' Id='EK52789332'><xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5'/><ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'><wsse:SecurityTokenReference><wsse:KeyIdentifier ValueType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier' EncodingType='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary'>ykCivrkfwQdj30aJid9VGnjtY=</wsse:KeyIdentifier></wsse:SecurityTokenReference></ds:KeyInfo><xenc:CipherData><xenc:CipherValue>Fi5B3uBMSp4nAKh3rLAs4DJQ5iCLoupE1oq3VOFueea1Y90xI200OFraV2mRS2ywsejH36nwy
    XYPuB5ZQScJampqZDtTR28cq890s4sEKFpycsNyNM9VScWaVoi4nKBKRIdGVoLgLf+NrmzJnXD
    6eb4F6tWWyw8g2FJel4=</xenc:CipherValue></xenc:CipherData><xenc:ReferenceList><xenc:DataReference URI='#ED13608949'/></xenc:ReferenceList></xenc:EncryptedKey><ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'><ds:SignedInfo><ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'/><ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1'/><ds:Reference URI='#wsuid-body-1f108c10-0181-11dd-838e-00144f2515b0'><ds:Transforms><ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'/></ds:Transforms><ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1'/><ds:DigestValue>UaW58GCrg/nrA/EfW+OyHP2DCio=</ds:DigestValue></ds:Reference><ds:Reference URI='#wsu-targetID-1f10b320-0181-11dd-aebd-00144f2515b0'><ds:Transforms><ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'/></ds:Transforms><ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1'/><ds:DigestValue>LFuszgJ412Fe8PRtK3W69RTXndY=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>K4iZoVGhuI41fj9BdXx7wUz/JEi2pqh60gZZta8tOfaVmC1PfNtPg61N0sYescfM4RmkQpDorS1d
    VB/DAJKz173HTD5rn/SuwmYgql4aVKPNlIDD90ZXoJ/mfzwT/Kei6yjWtvCYthCxaUtP/LFDB/dA
    mr1OUAj9X2DHkzF6g=</ds:SignatureValue><ds:KeyInfo><wsse:SecurityTokenReference><wsse:Reference URI='#sap-9'/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security></SOAP:Header><SOAP:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' wsu:Id='wsuid-body-1f108c10-0181-11dd-838e-00144f2515b0'><xenc:EncryptedData xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content' Id='ED13608949'><xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/><xenc:CipherData><xenc:CipherValue>lZkC7zZZfqBUg5rnqMZypi5ZvnPBvw36fjeFmCDQ5DMDjKXShO4apBjBE3gUsLGL1TMli18D0NWK
    dmVHQTePitGhvQ7YiyaXgjekZckS2P91Qv/9Zut5/hzCYhgVarnUgGmr8Qi4aSYXCY0oBD6SzVXy
    /UoQHPASF3mhYPaFBtmTJu2dHmV6v4HTKC+Om0</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></SOAP:Body></SOAP:Envelope>
    Response:
    HTTP/1.1 200 OK
    Date: Thu, 03 Apr 2008 13:23:54 GMT
    Content-Length: 9511
    Content-Type: text/xml
    Set-Cookie: JSESSIONID=cTPmH0hKYvKqK427JJb573FT1RWZhHY5l7XnLlsjsk6yRkS2g5y6!1973031667; path=/
    Connection: close
    <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><env:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1"><xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"></xenc:EncryptionMethod><dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><wsse:SecurityTokenReference><wsse:KeyIdentifier xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" wsu:Id="Id-dgdMMmsGkjae8aSYF_59_xwe" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">adHS0gj0CBQymaNnAlGJphSCB/Y=</wsse:KeyIdentifier></wsse:SecurityTokenReference></dsig:KeyInfo><xenc:CipherData><xenc:CipherValue>mbOmTXSiYuEiWHbP3dbrDXFpZaSoQ084wMBt7uRxNo49p1fpQBkDpr/H2wPNbHy4qzSTVzP7EESzWFjFEb/7BH3dt4JuyzBFH1M0X77YBW5YHNGpiUmj934ziydojqcU6jWBsUaFxXsAPmvy0q3vVk8xnZcQHxMNhPS5ebK9o=</xenc:CipherValue></xenc:CipherData><xenc:ReferenceList><xenc:DataReference URI="#Id-yMgwZrtQctSvW1mT1sDWdZ8D"></xenc:DataReference></xenc:ReferenceList></xenc:EncryptedKey><wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="Id-2DXBQHwdRE0oquWQV0mjtw1U" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">MIIFVjCCBLgAwIBAgIKfps5MgABAAADHjANBgkqhkiG9w0BAQUFADByMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDZWRzMRQwEgYKCZImiZPyLGQBGRYEY29ycDEUMBIGCgmSJomT8ixkARkWBGFtZXIxGjAYBgNVBAMTEUVEUyBFbnRlcnByaXNlQ0ExMB4XDTA2MDUyMzIzMDY0OVoXDTA4MDUyMjIzMDY0OVowYzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlRYMQ4wDAYDVQQHEwVQbGFubzEMMAoGA1UEChMDRURTMQwwCgYDVQQLEwNTRFMxGzAZBgNVBAMTElNTQVdlYlNlcnZpY2VzLURFVjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0qRmvQkxnPnEZQNSabPVwM6sEf8vFUOAlgQ9uuiDImVmDw4Afg45zbmTBeDdv4wsIap7kI4VJhv60SdOQg6i1mIEi83Qk7UJYD8XvKuOalSLYhHu92lsp0kIZlAdzipVd1Pp0cI3wSvP6o9zfX0gALpisf8rGJ1CkVWbtHaVp0CAwEAAaOCAwAwggL8MB0GA1UdDgQWBBTKT4KKuR/7BB2PfRomJ31UaeO1jAfBgNVHSMEGDAWgBQs1VMj8K2MzSTgyXMku5Aji1VTLzCCARoGA1UdHwSCAREwggENMIIBCaCCAQWgggEBhoHFbGRhcDovLy9DTj1FRFMlMjBFbnRlcnByaXNlQ0ExKDEpLENOPXVzcGxzc2NhMDAyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9ZWRzLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGN2h0dHA6Ly93d3cuZWRzLmNvbS9jcnRyZXZsc3QvRURTJTIwRW50ZXJwcmlzZUNBMSgxKS5jcmwwggEPBggrBgEFBQcBAQSCAQEwgf4wgbYGCCsGAQUFBzAChoGpbGRhcDovLy9DTj1FRFMlMjBFbnRlcnByaXNlQ0ExLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9ZWRzLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBDBggrBgEFBQcwAoY3aHR0cDovL3d3dy5lZHMuY29tL2NydHJldmxzdC9FRFMlMjBFbnRlcnByaXNlQ0ExKDEpLmNydDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIEsDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiHir5XhY3E8WRG4fByW6DrdJZLYak4iKE9PwvAgFkAgEEMBMGA1UdJQQMMAoGCCsGAQUFBwMBMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQEFBQADgYEALsVozc1aVcPNBVsRXRbAiStchxG2fKDOt9kRzL6BHtQa/fkp81EjOBhETn8N1IHLUsINn05wGgdDA2UszjLtRIpQmdpCyh2gzFW8Dlx5X7vJyvJsoDOPDBArv55dTjCEfok1oz3ux3mrVotuvr1pKIVTr7ylpRM8p8GBXw=</wsse:BinarySecurityToken><dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></dsig:CanonicalizationMethod><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></dsig:SignatureMethod><dsig:Reference URI="#Id-wS1xP_ArcYYXY4qkqYznI7_W"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>tr3NrozQWsKrvH38naIEnQXrzgQ=</dsig:DigestValue></dsig:Reference><dsig:Reference URI="#Id-1vPAqVSMhSLH3WiBQkTTfldz"><dsig:Transforms><dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xsd n1"></c14n:InclusiveNamespaces></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>AUWlqeyq6w5LQnggK5dT6flLUU=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>Yx5Pre8VChTLOhPVln5xhO21dM93a2FPxQTsZY1BBIWlqeHkAEQqXvhI/EU459QZIGDOubLK0Z9AT0SRmDOgtnWNBT0duqveQ1Ippbd0hXaehW48ObrMIKnYfq5ub1kNYv9mslybPRZw9OaiijNmLfIty8qc8ctRV0lFwAjcQyk=</dsig:SignatureValue><dsig:KeyInfo><wsse:SecurityTokenReference><wsse:Reference URI="#Id-2DXBQHwdRE0oquWQV0mjtw1U"></wsse:Reference></wsse:SecurityTokenReference></dsig:KeyInfo></dsig:Signature><wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-wS1xP_ArcYYXY4qkqYznI7_W"><wsu:Created>2008-04-03T13:23:55.459Z</wsu:Created></wsu:Timestamp></wsse:Security></env:Header><env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" wsu:Id="Id-1vPAqVSMhSLH3WiBQkTTfldz"><xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Content" Id="Id-yMgwZrtQctSvW1mT1sDWdZ8D"><xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"></xenc:EncryptionMethod><xenc:CipherData><xenc:CipherValue>LB6IKwEJgvTPdPGNeIzcpjPjC9GXi3sou5PaCnF3m4x6ToA6gDV5Sw/ODnCEeqFURgWFX8ZgxYF9YJdyj7ERAifs8MNBh/rHCitT02mU8pirwGdqSXlfCX4KYsHtUnyiGKbbMCwvCCs4LgBPnx8tCN39aazA1Ge/5JPfwupYMU/lAbyajdP1qva/gxhMCqGkgAnQgB1TJDfARvDsJnx6p2zqKsnRnNreBFClyBG7GHeMvpnzg4poPCFlj2baIoK2CSQmVbPdcPk4rgg1PAWDQwIIzBCKpZjysHeb/sW9jObekbnn4mCnUdzjRERoklstpZNeWKi/jLEaNsIX1ixhsUyWIyknYGaBjDiiGqmS6BIO1RHu0SydiMv1L/FzIWgyO9VhilGdTWsVDP6CxljxTqg41bobuPazkjQHyBK9rCGQI9J/bjSiA2S6FBDHxhA6SfDjyhvGzDhGNLMd/***2ieUGQWg/atFbqItqW2HZzb7T0cuIiROBYaGLUbWnghcUXAn9dV38GbCMfWk65OhpkD5EQXr/5bPxK41L3sPIrAs2JnMM9nLuj6gLo35VMlsdVQ1c0o3JYQ4JARnSlnUrgW20Cilwf3Fn2m7Yj4QicC6RUhChEudnbgYIjqq0Ypc8BsjJWAPYRuVAUVArINqgUjCNuOxQKV3dyEayS0lZ8UOBfopGBnIlEDS9h62ZIiIKfRhCD6xLsY1PED7K5ZHRvj2TEtQtYoZxeTNDH7/IdukO/cATF9B0DhSvx2YK8EzlG3pygcLGeHZ4DfwmGC5lnO5NZrqFaHXa1LNNgZ9H1rezZyOfizbvT/O5mC8tvINNvP5Ik37OdD6Lmjnc4u0gAKee6QqQ7uk8A6xbrjrnOWp46vnoNmvMZxyAMAD8xFBz9b8MVHu0IJX5etLdRbjsSsMYNpUomqFjfweFe3NeHESUA5IhkYUQVNNwJJ3MCpJDWWHFNLEbzRoUolXVOQhC0PC6j6KmHQH2yib0KWKKJn7kLrUtgGazJMatLDhWDU5oEtZbDJzauxikxto0R6ZirhjKqmVCeVu51yrbW4lgC2upXxJsQ2q5igBaX7Qvz4D1ICkp1m7CRG7cWrU6MfBSXusRsPIp/7wJsdBpXSPb97cZi6y82EP6iQhsyRJ9YODUr22WObb4CvIYo8bDFW1Sw6BImoqkgsoXB/j2oNp0g6vLhYy0OjF5LAdDbhDk23WA00KGj9xAHEPVkqfXdivfc3quxWdpIBri0JnQGA/T1GsxwM4YKvhp5hPl28sgLeo7/I0DstkK6Jispkt5/03N364bRQBAHykAqUAyDvMHz8jiZK0Jo2cnTDTzoDtDi9q2wbSI25lh31FZ68kKJ1t399VRdF4JlSKvaXE8pj1ljE3J6GsII6haD3W17Kns2hmnduL0pEeChUgq0VrXaK8k5e0CR1JdmzVEHNo7WKWwB901cOrtRfxh1yQWvw0dHCSlxzAlISAb7Y2t0MlIoITIKi9XzJSpbxtp5zCQiup3PPDni1wQWotYd9WVZ2Zs2KxDkusDbENOAu68RjtWoOQxGXPrek73CQ9ja2D6doNjdbwX9Exrhqlek9507Sn0J2RO5kJG6huXD3TTXcBcBlD8HYq76JfSNtqgpUwKztPCxaECMmvTm4n1YRT5pkpKfOmlx262TJllv1l2B5cs3f6ODWf/ULarjwMPT2ajviYvCDXl4Kl8HNcmXKhR3W8IzCvWCsPwwDoFbjCk5Xkdd6IVPAX9i0LP5hZqS1bMrJnTreNTVd4glne7T6SdjkFt2MR1UJnsNHlVDoeGhb5VhfphgPg2r1DUyY7k3QlXHGxCBctjlkTUVg9D0NgWf4JrE2KXtdCPR/gX7HjrR6wq24UsibqOH5yi2Zh2hGwP2OWrPRQ6QMqIdW2voAux0GOkL7Ip8GCRml5eilopmRyh8D3PxWw8CwfC81slylodVHvGP8AjGE9cddQhMzQ2s96ZPQVTLEo734UQFkH511HtJGWVCTbxGBmtpEyoJZSJJ9CeG2sXuwEGF7YXR31xJJZbtOKFyskQw3BJGb1SE35iF5lr0hshYB1/gm2YmlTX68nZtux9NWRIKnJ3EHvWUc9UIudzoEMf0LyLZm5pFtkZAUQ16F4BfqEVJekVlUBOs1dCSYN6lUcsVzinhUcY1eBni75vEXaO8zSTy4ZwcOiGYvR9QK2bSuzYen1LKBaFK6UIAVstr29avGAGp5nk3qM63/05rUv2jnDM6XYIoFSx1lpE7SwtvbiRUQjgUA4ZX7Oa7Mp9HJj5W0o7ZVViKbYTtxux5/2AXgXxLo/i3YsHd7BUE/2KTjUrKokTYUzCgTlXkSmYOfRY1wdxeixrLfbSWBD1Y4ZbcMw3l/57XIPmGl42HrRyEFIxGnt7kQHR9A3abfJ93E0Y8AMiQuhG2/WTZho/IzxQ/OfDJm78o97K10pbe7OUIrfpPNTfM3cenEd37ZFWI67yPNwYfiZw8E7uks8GIKSAqrt7q55C10EpmizEcydD5EKtGyElXk6ifr3GO6WbHJNUp6FvgyHQTF6VXRiC91Rv/ZvUQggxRDyF6HibOq5BqDwTbMY0OnbB6nR3KlGYfhkBfEUiqbd10HYzCzWx0uGv54swAwsRUtOQFMpbr5B17yXdE5vGN2uTm02Bgr3EwOUyuw2ttgdUedDH8APmOlDr23wPiFljsTgWbbX/UZQGCyhNxa8avQtDdlymu8e8PS5tMupjMSkJtULUUXQyoKGwcXwwvp25iubNODEt5aZNt45bGKwOW5P3Xzu2ZJ6tAtW/zh7NfN1EHVZIwIlxWgPaag0ComeirsmZfNu3W2wge7Cg9aOYws81iIRaLa0YgYWZwH3C6yTRRQcM8fx1U1TiK2tIkFcc4iAjefZKMHBsodtTzo4EYaYvb9SyjGgZLTMYSlTbpx31Ot0T/t8kFxpML/ObDgoKoxWUVXxfD74HDW/0Uo9JDgdaV/lxJ2CJ7y8gb4ayKsVRNB4BmP5OzA/q9vzZWgtfoM4ODu//vsAed9Dvi4f1pJt5Cf8WWxv1PtWS4gvFe87a03kyhwSzI4obai23oYlCcyrUyL9LBZCwcBgn4tDcno6HPIHT2iEpi00sTuTD2bqXyTkXrxgzGSwlfBzCXr7xczoZDJoU5oj5t59cyq/faUZZkhc0bb8dhOH2/oYcanpfdtNS64VeO42eXaPbkMP00IrHTAUb2KxXQa7h80vB3LMA29cS3EBaJ8pnIJ/sPh0bT5A/FiiiJVJNm8g7EBcvd2nbJWRAkVNp1SxLPoUKF1dRt3OiJwhbdOASOnmJS8IXRjskuIYRsMgXSNdlMGxadedsdB9TKRvgzGkutWu9mQ3+0XJJIp7S23E8b3OLH1CAxhH3wyWu8TmeksImbGc0VY7oSTTtNNWOdeRDQ==</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></env:Body></env:Envelope>

    Any thoughts???
    Appreciate your input.
    Thanks,
    Laxman

  • Error at SOAP response channel

    Dear All,
    I have created a synchronous PROXY to SOAP scenario. But I am getting the following error in the receiver SOAP Adapter.
    Message processing failed. Cause:
    com.sap.engine.interfaces.messaging.api.exception.MessagingException: SOAP:
    response message contains an error XIAdapter/PARSING/ADAPTER.SOAP_EXCEPTION -
    soap fault: System.Web.Services.Protocols.SoapException: Server was unable to
    process request. ---> System.NullReferenceException: Object reference not set
    to an instance of an object.
    --- End of inner exception stack trace ---
    Please suggest what may be the reason for it.
    Thanks and Regards,
    Rana Brata De
    SAP PI Consultant

    Hi,
    We have faced similar problem in production some time back .
    At target system end web service validates the payload below inserting into back end system (d/b).If the validation fails then it throws the error to PI system .
    For us the backend system notified that there end front end service validation failed due to data issue and thrown exception to PI.
    Share the payload to target system folks and ask them to check ,they will have test suite to test it from there end . If not share the time at which you received error,they will check there logs and update you on the cause .
    Regards
    Venkat

  • Reading Header data in a SOAP Envelope for SOAP Sender Adapter

    Hello All,
    Am using a SOAP sender adapter and want to use the data inside the SOAP Header for some routing purpose(extended receiver determination). Any SOAP message coming into XI will look something like below. But XI will pass the contents of <SOAP-ENV:Body> to Payload and <SOAP-ENV:Header> to the SOAP Header category you can see that in SXMB_MONI.
    Is there a way to read the data in my SOAP Header to be later used in my extended receiver determination.
    <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:Q-ENV="/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
         <SOAP-ENV:Header>
              <Q-ENV:Header>
                   <Q-ENV:Sender-Id>1</Q-ENV:Sender-Id>
                   <Q-ENV:Receiver-Id></Q-ENV:Receiver-Id>
                   <Q-ENV:Correlation-Id></Q-ENV:Correlation-Id>
                   <Q-ENV:Message-Id></Q-ENV:Message-Id>
                   <Q-ENV:Date-Sent></Q-ENV:Date-Sent>
                   <Q-ENV:Document-Type></Q-ENV:Document-Type>
                   <Q-ENV:Message-Format></Q-ENV:Message-Format>
              </Q-ENV:Header>
         </SOAP-ENV:Header>
         <SOAP-ENV:Body>
              <Q-ENV:Body>
                   <Q-ENV:Content-Type>text/xml</Q-ENV:Content-Type>
                   <Q-ENV:Message-Type></Q-ENV:Message-Type>
                   <Q-ENV:Encoding>UTF-8</Q-ENV:Encoding>
                   <Q-ENV:Message-Body>
         </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    Thanks for your replies in advance.
    Regards,
    Prashanth

    Hello,
    but they were not getting any response back from XI and the sending system kept resending the message.. may be it was acting like a HTTP post.
    The method that is used by the native SOAP Adapter is always HTTP Post. Not sure why you are not getting a response, have you checked the outbound firewall of the sending party or the inbound firewall of XI? To which SOAP URL are you sending to?
    Hope this helps,
    Mark

  • Wsdl - soap response...

    I am working on java ,using Eclipse wit wtp and Apache Axis. The soap request is sent, an xml file is parsed and I want to generate soap responses from the xml file.
    Now i can send a soap request, parse the xml, but the response am getting is not of soap format, its jus a simple data...
    For eg.. if the request is add no.s ( 5+ 7) i get the sum(12) or if i request for author of a book from i just get author's name.. 
    Instead i want it as a soap response... some thing like this for requesting the stock price...
    <?xml version="1.0"?>
    <soap:Envelope
    xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
    soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
      <soap:Body xmlns:m="http://www.example.org/stock">
        <m:GetStockPriceResponse>
          <m:Price>34.5</m:Price>
        </m:GetStockPriceResponse>
      </soap:Body>
    </soap:Envelope>
    How do i get the sopa response using the wsdl file that gets generated... ????
    Or is there another way of generating the soap responses.. ?
    Plz help me out...

    Hi,
    All that you want to do is trying to call a web service and get the response from it, you can use the WSDLs from any weather or lets say google. From XI you can call it and you would get response in SOAP format.
    If you want to create a web service, create a SOAP to RFC scenario in XI where RFC returns you some thing that you wanted in sync fashion. Now use the WSDL genrated from this scenario and import in XI for another scenario.. where it could be a HTTP to SOAP. Now you would get the response of RFC in SOAP format it self..
    VJ

Maybe you are looking for