We are recieving soap response with spaces from backend application, when i see in datapower probe unformatted format i can see spaces. But Consumer team are recieving response without spaces from datapower webservice proxy.How can we send the unformatted response or how to preserve whitespaces within the response?
But when i test using soapUI I am getting response as expected with spaces.Please suggest
Actual Result :
<restopic:SequencedText>
<seqtxt:Sequence>00010</seqtxt:Sequence>
<seqtxt:Text>% LOB: Facility, Professional Effective Date: 07/11/97</seqtxt:Text>
</restopic:SequencedText>
Expected Result :
<restopic:SequencedText>
<seqtxt:Sequence>00010</seqtxt:Sequence>
<seqtxt:Text>% LOB: Facility, Professional Effective Date: 07/11/97</seqtxt:Text>
</restopic:SequencedText>
Thanks in Advance!!
First of all, don't trust the probe!
It will format messages according to what it "thinks" is correct and spaces might "disappear".
Make a XML File capture in the default domain and grab the archives from there to see how it really looks!
DataPower won't touch the XML element values so my guess is that it's either something happening after the message leaving DataPower or some conversion of character code or something messing up your spaces.
In the file capture you will be able to see both incoming and outgoig message and then you'll know how it looks.
Related
Hy Guys,
I have a Web service problem. The used environment: SOAP - TOMCAT+AXIS2 - Gigaspace - Magic XPA 3.3
I have made 2 closely same external xpa program what gives back a blob in the Task's property sheet's Return value. It's "answer" back an XML, the simle different is that the first one make (XPA merge) a smaller (18KB) file (from a Filtered DB source), the bigger is write out the whole record aggregation. (1025KB)
When the soap UI receives the first one, everything is fine, i got the result XML on SOAP side. The bigger one shows this error:
With11Endpoint:
<soapenv:Fault>
<faultcode>soapenv:**Server**</faultcode>
<faultstring>**Failed to serialize node**</faultstring>
With12Endpoint:
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:**Receiver**</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">**Failed to serialize node**</soapenv:Text>
</soapenv:Reason>
The only different is the size of files i think so. I have read some option to solve it like BasicHttpBinding's MaxReivedMessageSize and MaxBuffer size, but i could not find them to change values.
Does anyone have experience in this solutions?
Best Regards,
Gábor
For the future. The XML what has sent contained wrong values. Not tipical XML invalid character, instead an character. So i you have a SOAP error like that, try to Validate your XML file to search an option to solve your problem. ;)
I am trying to test a webservice's performance, and having a few issues with using and passing variables. There are multiple sequential requests, which depend on some data coming from a previous response. All requests need to be encoded to base64 and placed in a SOAP envelope namespace before sending it to the endpoint. It returns and encoded response which needs to be decoded to see the xml values which need to be used for the next request. What I have done so far is:
1) Beanshell preprocessor added to first sample to encode the payload which is called from a file.
2) Regex to pull the encoded response bit from whole response.
3) Beanshell post processor to decode the response and write to a file (just in case). I have stored the decoded response in a variable 'Output' and I know this works since it writes the response to file correctly.
4) After this, I have added 4 regex extractors and tried various things such as apply to different parts, check different fields, check JMeter variable etc. However, it doesn't seem to work.
This is what my tree is looking like.
JMeter Tree
I am storing the decoded response to 'Output' variable like this and it works since it's writing to file properly:
import org.apache.commons.io.FileUtils;
import org.apache.commons.codec.binary.Base64;
String Createresponse= vars.get("Createregex");
vars.put("response",new String(Base64.decodeBase64(Createresponse.getBytes("UTF-8"))));
Output = vars.get("response");
f = new FileOutputStream("filepath/Createresponse.txt");
p = new PrintStream(f);
this.interpreter.setOut(p);
print(Output);
f.close();
And this is how I using Regex after that, I have tried different options:
Regex settings
Unfortunately though, the regex is not picking up these values from 'Output' variable. I basically need them saved so i can use ${docID} in the payload file for next request.
Any help on this is appreciated! Also happy to provide more detail if needed.
EDIT:
I had a follow up question. I am trying to run this with multiple users. I have a field ${searchuser} in my payload xml file called in the pre-processor here.
The CSV Data set above it looks like this:
However, it is not picking up the values from CSV and substituting in the payload file. Any help is appreciated!
You have 2 problems with your Regular Expression Extractor configuration:
Apply to: needs to be response
Field to check: needs to be Body, Body as a Document is being used for binary file formants like PDF or Word.
By the way, you can do Base64 decoding and encoding using __base64Decode() and __base64Encode() functions available via JMeter Plugins. The plugins in their turn can be installed in one click using Plugin Manager
Situation: I am trying to call the LinkedIn API from a ColdFusion CFC to get the user's profile and network (connections). The LinkedIn API states that to do this you must call a URL with scope=r_fullprofile+r_network.
Issue: ColdFusion is automatically encoding the URL, so the plus sign is getting encoded, and LinkedIn is rejecting my call. Is there any way around this? I've posted a link below to some code snippets on github which I believe illustrate the issue.
https://gist.github.com/4535364
Any help would be appreciated!
I have searched around on this for a bit and I am seeing lots of examples where ColdFusion is not playing nicely with the LinkedIn API. So I'm afraid if you do get passed this issue (although I have not come up with an alternative yet) another will crop up. While searching I found several suggestions from people to use the linkedin-j, A Java wrapper for LinkedIn APIs instead. Here are some of the references that I found:
Working example Coldfusion and Linkedin API
LinkedIn-J does not return educations
401 Unauthorized response. API people/~ and people/id=; ColdFusion, cfhttp
Problem updating status - 401 unauthorized - ColdFusion
linkedin-j Getting Started
Side Note Your github code example is making a cfhttp call to 'receiver.cfm' but you called the file 'cfhttp_receiver.cfm'. In this line:
<cfhttp url="http://#cgi.http_host#/sandbox/receiver.cfm?scope=#url.scope#" method="post" resolveurl="no">
The scope field is a space delimited list.
The + character is commonly used as a shortcut for space, since it's more readable than %20 (which is what space encodes to).
If using a plus character results in an encoded plus (%2B) being sent, then you are left with two other ways of putting the space into the URL:
using a literal space character, or
using an encoded space %20
Try both of those options, ideally using a network snifer (e.g. WireShark) so that you can see accurately what is being sent.
Update: As per comments below, %20 is correct, but the signature based string needs to be encoded again, so for that the % becomes %25, giving a result of %2520.
I haven't seen any documentation for calling XML-RPC by inputing certain strings and get respone of some strings in c++ by connecting to an XML API. This is a documentation provided by the server. I can't figure out how to do this
A client can interact with a Pandorabot by POST'ing to:
http://www.pandorabots.com/pandora/talk-xml
The form variables the client needs to POST are:
botid - see H.1 above.
input - what you want said to the bot.
custid - an ID to track the conversation with a particular customer. This variable is optional. If you don't send a value Pandorabots will return a custid attribute value in the <result> element of the returned XML. Use this in subsequent POST's to continue a conversation.
This will give a text/xml response. For example:
<result status="0" botid="c49b63239e34d1d5" custid="d2228e2eee12d255">
<input>hello</input>
<that>Hi there!</that>
</result>
The <input> and <that> elements are named after the corresponding AIML elements for bot
input and last response.
If there is an error, status will be non-zero and there will be a human readable <message> element included describing the error.
For example:
<result status="1" custid="d2228e2eee12d255">
<input>hello</input>
<message>Missing botid</message>
</result>
The easiest way to communicate via HTTP in C++ is to use a library designed for that purpose. For example, libcurl provides all the facilities you would need to send and receive the kind of requests and responses you showed in the question.
I am using RestWebservice for few basic operations , like creating/searching. The request xml looks something like this
<customer>
<name/>
.....
</customer>
For a successful operation I return the same customer XML with extra fields populated in it(eg. systemId etc which we blank in the request) .
with Response.Status=2000
For an unsuccessful operation i return something like this with different error codes .
e.g Response.Status = 422(Unprocessable entity)
Response.Status= 500(Internal Server Error) and few others..
<errors>
<error> An exception occurred while creating the customer</error>
<error> blah argument is not valid.</error>
</errors>
Now i am not sure , whether this is the correct way of sending the errors to the client. Maybe it should be present in the header of the response.
I will really appreciate any help.
Thanks!
The correct REST approach for errors is to use the HTTP status codes (as it sounds like you are doing). There is a bewildering array of them (as you can see here) and you might be surprised to see how many may fit most common situations.
As far as friendly error messages, you have 2 choices. First, you can provide a text description of the status code after the status code in the HTTP response (see the Wikipedia article on HTTP for more info). This text is determined by the server--not the HTTP specification--and gives you some flexibility in the specific message you send; most server-side frameworks give you a way to set this text programatically. However! It is a best practice not to abuse the status code description, because you can't guarantee that the user's web client will read it or not (in favor of reading only the status code and using the standard HTTP descriptions). I would only recommend using this approach if your status descriptions are simple and you control the server and the client (so you know what you are getting). In my experience, this approach works pretty well for the 5xx range of codes, but I wouldn't use it for much else.
Your second option is what you are already doing: to return an error status code and a description of the error as the body of the message. That is a best practice; if it is working for you, no need to change. It is probably helpful to think of this as "additional information the errors" rather than the error message itself (which would be the text after the status code in the HTTP response).
I'd wrap the XML in "Request" or "Response" wrappers.
E.g.,
<customerrequest>
<customer>
..
</customer>
</customerrequest>
and more importantly:
<customerresponse>
<status>success | failure</status>
<customer> <!-- If success -->
...
</customer>
<errors> <!-- If failure -->
<!-- never underestimate the value of having a machine-friendly error code
for each possible error, or critical/non-critical errors -->
<error code="0001">An error occurred</error>
</errors>
</customerresponse>
This also means that as your service matures, you can add extra non-data fields as required within the request/response tags. Or a reference number. Or authentication details.
If you were using SOAP, you could use the existing error handling that SOAP has built-in, although I have personally found it rather restricted (not that I investigated too deeply).