I have method in Business Layer, which contains some optional parameters.
When I am trying to invoke the method from the WorkFlow 4.0, it is expecting me to pass
the optional parameters also.
Is there a way that I can avoid passing optional parameters to the method.
The method that I have is SendEmail(string emailTo, string domain, string smtpAdress = "POP");
When I call this method any where in the code.. I am just calling the method like
SendEmail("xx.com","PFE"), which is working fine
But in the Workflow..it gives a compilation error saying that
" 'BLEmail' does not have a public instance method named 'SendEmail' matching the parameter types, generic type arguments, and generic type constraints supplied to InvokeMethod 'InvokeMethod'."
When I am passing the optional parameter, it works fine..but it loses the whole concept of optional parameter.
Please help..
Thanks and appreciate your feedback.
Sam.
InvokeMethodActivity does not handle optional parameters. You have to provide all parameters regardless if they are optional or not.
Related
This is my code
Pipeline
Pipelets java
Pipelets XML
I'm passing a parameter(SKUs) value into a pipeline from js.
The value is getting passed into the pipeline but not into pipelets.
It gives me parameter SKUs in not available.
Thanks in Advance
you are trying to pass a String to a List. You could try again by making Pipelet Input Parameter "SKUs" type "java.util.List<java.util.String>".
If your SKUs parameter is passed to the pipeline using JS client (via post or get), your pipelet needs to process type String[].
I actually solved my problem before posting, but I wonder if there are any better solutions?
Also if there is somewhere where there is a way to use list as-is?
I am writing a simple get endpoint if F# which needs to accept a list of strings as an argument.
I take that list as the input to a query that runs as expected, I am not worried about that part.
The problem I am facing is as follows (minimal implmenetation):
When I define the endpoint as:
[<HttpGet>]
member _.Get() =
processStrings [ "test"; "test2" ]
it returns as expected.
When I change it to:
[<HttpGet>]
member _.Get([<FromQuery>] stringList: string list) = processStrings stringList
I get an error:
InvalidOperationException: Could not create an instance of type 'Microsoft.FSharp.Collections.FSharpList`1[[System.String, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]'. Model bound complex types must not be abstract or value types and must have a parameterless constructor. Record types must have a single primary constructor. Alternatively, give the 'stringList' parameter a non-null default value.
Which doesn't make much sense to me, as I am using a list of strings, which in C# at least defaults to an empty list.
So I assume this comes down to how C# and F# interpret these signatures, but I am not sure how to resolve it.
I tried this signature and received the same error as above....
member _.Get( [<Optional; DefaultParameterValue([||]); FromQuery>] stringList: string list) = processStrings stringList
In the end using the following did solve the problem.
member _.Get( [<Optional; DefaultParameterValue([||]); FromQuery>] stringList: string seq) = processStrings stringList
I assume it was solved because seq is just IEnumerable, and then presumable list isn't just List from C# (mutable vs immutable). But is there a way to use an F# list in [FromQuery] parameters? Would [FromBody] have just worked? (No is the tested answer) Is there a way to add a type provider for an endpoint like this?
Is there something else I am missing here? Mine works now, but I am curious to the implications of the above.
I have not tested this, but I would assume that ASP.NET does not support F# lists as arguments. I would guess that taking the argument as an array would be much more likely to work:
[<HttpGet>]
member _.Get([<FromQuery>] stringList: string[]) =
processStrings (List.ofArray stringList)
I just spent some time troubleshooting an aspect of Spring MVC's default handler method parameter resolution and I'd like to ask those closer to the project if this behavior is intended or if it'd be reasonable to open a ticket suggesting a change.
The issue has to do with the default resolution of POJO-style objects in method parameters like this:
#RequestMapping("/endpointwithparams")
public String endpointWithParams(EndpointParams params) {
// Do some stuff
return "viewname";
}
With no annotations or custom argument resolvers, Spring will attempt to bind the EndpointParams object by matching request parameters to its field names. It will even run validators if any are configured. This seems great - it lets me write simple POJO objects to organize related sets of parameters without having to have a custom argument resolver for each one.
The part that throws me off is that after the EndpointParams object is created it will also be automatically added to the model. This is because the actual resolver of this parameter will be a ModelAttributeMethodProcessor with its "annotationNotRequired" flag set to true. I don't want this parameter added to the model - its presence causes some trouble down the line - and it certainly wasn't intuitive to me that I should expect that addition to happen for a parameter that wasn't annotated with #ModelAttribute.
This behavior is also inconsistent with what happens when you have a "simple" request parameter like this:
#RequestMapping("/endpointwithparams")
public String endpointWithParams(String param) {
// Do some stuff
return "viewname";
}
In the above example, the String param will be resolved by the RequestParamMethodArgumentResolver, which will not add anything to the model.
Would it be reasonable to suggest that better default logic for non-annotated POJO parameters would be the same binding and validation that currently occurs, but without the automatic addition to the model? Or is there some context I'm missing that makes the full #ModelAttribute behavior the best default choice?
Given a JSON string of the form {"$type":"MyType, MyAssembly","seed":0"}, why can't JsonConvert.DeserializeObject utilize the JsonConverter associated with "MyType"?
I've tried decorating the MyType class with a [JsonConverter(typeof(MyType))] attribute. Doesn't work. The custom JsonConverter's ReadJson method is never called.
I've tried adding the custom converter to the serializer's settings Converters collection and made sure the CanConvert method returns true for 'MyType' and the CanRead method returns true. Doesn't work. Neither the converter's CanConvert nor its ReadJson method is ever called.
The DeserializeObject method needs to be able to deserialize a JSON string containing an object whose type is unknown at compile time, but whose type is embedded in the JSON object via the special "$type" member. So don't suggest using DeserializeObject<T> or point out that it works for members, whose type is identified in the contract before hand.
FYI, this problem generalizes to cases where the deserialization needs to identify the object type solely from the embedded "$type" member, so for example, it also fails to resolve a converter if the JSON object is in an untyped JSON array, not just at the top-level.
Basically, an object cannot survive a round trip through the serialization/deserialization process, because although the WriteJson method will be called for the Converter when SerializeObject is called, when you subsequently pass the JSON string to DeserializeObject, it fails to call the converter's ReadJson method, and instead constructs an new instance and uses the basic member population routines.
I need to develop a web method that has many parameters. In REST, I understand a webservice has its own significance by attaching itself to particular entity and HttpVerb determines operation type.
This webmethod cannot be associated with an entity, it just calls a stored procedure and returns data, so I assume it only has only a GET method. But it has too many parameters to be fit into a URL. So, do I need to consider using POST method instead of GET.
It wouldn't really pass as 100% true to REST but you can have one web method that you call that looks at query string part of the url to get the additional parameters.
You would have a web method with a route of '/GetData'.
domain.com/GetData?Parameters=firstParm=1^secondParm=info^thirdParm=test
then in the web method, you would check the query string for Parameters and then split the string by the '^' symbol.
or
domain.com/GetData?firstParm=1&secondParm=info&thirdParm=test
this you would have to do a query string for each parameter.