I have a wcf service having the following operation:
public NewPCNResponse CreateNewPcnExtended(NewPcnExtendedData newPcnExtendedData, string chargeBand, string deviceId, decimal? usageCharge, string plateType)
Note the camel cased parameter chargeBand. The problem is with all the camel cased parameters but I am taking this one for demonstration.
I am using SoapUi to test the calls and the following is the relevant part of the SOAP request:
The element is camel cased and even though it is nullable, it comes thorough as an empty string as shown in the following screenshot:
this fails the validation which I have down the line.
However if the argument is pascal cased, it comes through fine
The easier solution for me to change the casing but I want to know the reason behind this odd behaviour and if I want to keep the argument camel cased what option do I have.
Related
And now, I am trying to rewrite my java application in Kotlin. And then, I met the log statement, like
log.info("do the print thing for {}", arg);
So I have two ways to do the log things in Kotlin like log.info("do the print thing for {}", arg) and log.info("do the print thing for $arg"). The 1st is delegate format to framework like Slf4j or Log4j; the 2nd is using Kotlin string template.
So what's the difference and which one's performance is better?
In general, these two ways produce the same log, unless the logging library is also configured to localise the message and parameters when formatting the message, which Kotlin's string interpolation does not do at all.
The crucial difference lies in the performance, when you turn off logging (at that particular level). As SLF4J's FAQ says:
There exists a very convenient alternative based on message formats.
Assuming entry is an object, you can write:
Object entry = new SomeObject();
logger.debug("The entry is {}.", entry);
After evaluating whether to log or not, and only if the decision is
affirmative, will the logger implementation format the message and
replace the '{}' pair with the string value of entry. In other words,
this form does not incur the cost of parameter construction in case
the log statement is disabled.
The following two lines will yield the exact same output. However, the
second form will outperform the first form by a factor of at least 30,
in case of a disabled logging statement.
logger.debug("The new entry is "+entry+".");
logger.debug("The new entry is {}.", entry);
Basically, if the logging is disabled, the message won't be constructed if you use parameterised logging. If you use string interpolation however, the message will always be constructed.
Note that Kotlin's string interpolation compiles to something similar to what a series of string concatenation (+) in Java compiles to (though this might change in the future).
"foo $bar baz"
is translated into:
StringBuilder().append("foo ").append(bar).append(" baz").toString()
See also: Unable to understand why to use parameterized logging
I have been using different forms of Mule's Expression language.
I couldn't figure out the difference between
#[flowVars.myVariable]
and
#[flowVars['myVariable']]
They both give the result when there is a variable. But why do they behave differently when the variable is not present?
Like if the variable being called is not available, then the first expression would result in a exception. Whereas the second expression just gives out a warning or prints out as is, if in a logger message.
Why is this difference?
Also when going through the documentation for Mule 3.6 I found that the second expression is not longer shown in the documentation.
Is the expression #[flowVars['myVariable']] being deprecated?
The difference comes from the way MVEL deals with these two different ways of accessing map entries.
#[flowVars['myVariable']] is equivalent to flowVars.get('myVariable'), which does not fail if the flowVars map does not contain the 'myVariable' entry,
#[flowVars.myVariable] treats the flowVars map as a virtual object, leading to an exception if the 'myVariable' entry is missing because in this case it doesn't resolve to a map get but instead to directly using an object member (either a field or a method), which must exist before being accessed.
I don't think #[flowVars['myVariable']] could be deprecated since it's a core feature provided by MVEL.
Reference: http://mvel.codehaus.org/MVEL+2.0+Property+Navigation#MVEL2.0PropertyNavigation-MapAccess
David has given a nice explanation around your question. To extend that explanation I would just like to add that you can use #[flowVars.?myVariable] to make your code null safe. This is equivalent to #[flowVars['myVariable']].
Regarding #[header:originalFilename], as David said this is not MEL. You can get a list of non-mel expressions which are commonly used in Mule applications in the following link.
http://www.mulesoft.org/documentation/display/current/Non-MEL+Expressions+Configuration+Reference
I have consumed WCF service in biztalk through "Add generated items". There is a method in WCF which takes an integer parameter. In orchestration I want to pass that method a default value or say I want to hard code input value. How I can achieve this. I have googled this question but didn't get any adequate result.
What I have done is declared an integer variable assign it a value, then I assigned that variable to a message of Integer type.
Now how I can assign this message to WebService Request type message?
or how I can transform integer type message to WebService Request type message?
There are a bunch of ways to do this:
If you are mapping the request from another message, you can hard code it in the map - click on the field in the RHS of the Map Editor and set the hard coded value in the Value in the Property box
After creating a (dummy) request message, you can set the value using xpath() in an expression message assignment shape
xpath(myRequestMessage, "//*[local-name()='NameOfFieldHere']") = 3; // Or set to it your variable
If the field is distinguished in your schema, you can use the distinguished field instead of xpath, viz in an expression message assignment shape:
myRequestMessage.NameOfFieldHere = 3;
(And note if its a multipart message, then it will be myRequestMessage.Part.NameOfFieldHere OFC)
One disclaimer: I've assumed the WCF service request message is trivial, i.e. just a single integer field. If your message is large, using //local-name() ... isn't recommended, since
There may be more than one node with with the name NameOfFieldHere
The XSL parser used by BizTalk is slow and resource intensive when evaluating large xml documents with //
Biztalk Scheduler Adapter is really helpful in this case. It generates desired XML on predefined scheduled set by the user. So fill up your XML with hard coded values and receive them through this adapter.
My error message is as listed in the header "Input string was not in a correct format" however the stack trace is even more cryptic
Microsoft.VisualBasic.CompilerServices.Conversions.ParseDouble(String Value, NumberFormatInfo NumberFormat) at Microsoft.VisualBasic.CompilerServices.Conversions.ToDouble(String Value, NumberFormatInfo NumberFormat)
This is worse due to the fact that nowhere in the project does it use "ParseDouble". I believe that this has something to do with the objectfactorylibrary but can't pin anything down.
Has anyone seen something similar or point me in a general direction?
Edit:
Additional information, this is a production only issue with local, dev, and QA unable to reproduce the error in any environment but Production.
The stack trace is referring to a method inside of the .NET Framework code, called ParseDouble. It does not exist in your code. This is why the entire namespace is included, so that you can tell where the method is defined. If it starts with Microsoft or System, it's not something you wrote.
You probably used the CDbl operator (it's that thing that looks like a function call to the uninitiated), and internally, the .NET Framework translated that to a call to the Conversions.ToDouble method, which internally calls the Conversions.ParseDouble method. These are implementation details that you should not have to be concerned with. Keep traveling up the stack trace until you find the last method called that is part of your code.
As far as why your code is throwing that error, it's almost impossible to say without seeing some code that reproduces it.
However, my psychic debugging powers tell me that you're probably trying to parse a string value into a number, and the method is failing because the string does not contain a valid number. Check the value of the string you're passing into the method and update your question. It's probably an issue of the language settings on your computer. Do you use a language where , (a comma) is the decimal separator rather than . (a period)?
It's basically telling you that you that it tried to convert a string to a number but couldn't as the string was not numeric (could have alpha or other characters in it).
The stack trace should point you towards the offending piece of code, if you're lucky you will have a line number. If this is a piece of code that usually works then take a look at the data (whatever it is).
I am trying to change the value of the parameter in IParameterInspector while doing the validation. The parameters that are string, works fine. But I need int as parameters. and if the parameter is not supplied in the RESTful call, I need to default it.
If the url does not contain anything for int parameter, it fails. However, in the same case of string parameter, if its not supplied, it takes the default values.
I use querystring format for passing the parameters. and I am just trying to run it on the browser.
Is there any way for this to work? or do I need to make all the parameters as string.
Thanks in Advance!
You need to make the parameters string. This will be fixed in the next version of the WCF Web APIS http://wcf.codeplex.com