I was provided a web service to consume by a vendor and they defined the namespace of the web service as follows:
http://company.com/ws/xml
I'm using IBM's BPM product to consume the web service and the tooling has trouble working with complex types that use that namespace. I'm trying to figure out if this is a problem with the implementation of the tooling or if the WSDL is invalid. Can anyone provide guidance?
I am rather of the opinion that the tooling is wrong. A WSDL's targetNamespace is a URI reference. There is nothing in the URI setup which cares about XML in particular.
The XML spec states that Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification. That however, doesn't affect XML namespaces, let alone WSDL targetNamespaces.
Now, I call this a "best practice", which more often than not simply stands for "defences against crazy things": avoid the use of (('X'|'x') ('M'|'m') ('L'|'l')) as much as possible. I've also seen it before - I was that "vendor" once. In my case, this "client thingy" was mapping URI segments to xml names, which, of course, could result in invalid mappings.
Related
We're using the Destinations service to configure connections to different kinds of systems. As part of this, we are using the "Additional Properties" section to add non-standard properties, such as my.custom.property=123.
We have successfully used the SAP Cloud SDK's MockUtil to write Spring integration tests that use the files systems.yml and credentials.yml as source for test systems.
However, we couldn't find a way to create an entry there that would provide a test system with a custom property like my.custom.property=123.
The erp section accepts only the properties known for ERP systems, such as sapClient. The general systems section accepts only the absolute basic properties name, type, uri, and proxy. Adding an unknown property in either section results in a runtime error because the mock utils are unable to parse the unknown property into the data classes with fixed structure.
Is there another way to mock a Destination that would allow us to include non-standard properties?
For example, the DestinationAccessorMocker looks promising, as it seems to enable setting up custom implementations of the Destination interface, but we couldn't figure out how to employ it.
Found an option that works.
MockUtil mockUtil = new MockUtil();
MockDestination destination = MockDestination
.builder("my-service", URI.create("http://localhost:1234/"))
.property("my.custom.property", "123")
.build();
mockUtil.mockDestination(destination);
Maybe somebody can confirm that this is an intended way to do this?
I am hoping to use a grpc-node client to talk to a microservice built in Go using the go-micro framework. I am running into an issue where go-micro defines method names using periods (.) to separate namespaces and method names, whereas grpc-node slashes (/). Is there anyway to configure this pattern to have these two processes talk to each other?
The gRPC over HTTP/2 protocol documentation defines that the path is constructed as follows:
Path → ":path" "/" Service-Name "/" {method name}
with this additional note
Some gRPC implementations may allow the Path format shown above to be overridden, but this functionality is strongly discouraged. gRPC does not go out of its way to break users that are using this kind of override, but we do not actively support it, and some functionality (e.g., service config support) will not work when the path is not of the form shown above.
So, the Node gRPC client is following the specification, and the alternate format used by go-micro appears to be hard coded in their code generation plugin (here). I would consider that to be a bug.
That being said, there is a viable workaround to match that method name format in the Node gRPC library. When you load a .proto file in the Node each client constructor function has a service member which is a plain JavaScript object that describes the service. It is a map of method names to method definitions, and each method definition includes a path member. You can modify the path of each method to match the pattern that go-micro uses, then pass the resulting service object to grpc.makeGenericClientConstructor to get a new client constructor that connects to the modified service.
I am wondering if it is possible to configure an Azure Function App to accept a URI-path ID as is typically used in RESTful services, e.g. /api/foo/1, where the function is foo. I haven't been able to find documentation on this and the binding information that I have found suggests that this isn't possible (I don't see a way to map it). It doesn't "just work" with the typical HTTP trigger (which supports /api/foo?id=1). In that configuration one receives a 404 response, I'm guessing because it doesn't know to call the foo function with the ID suffix in the URI.
In case it matters, I'm using C# to write my function.
You are correct that URI parameters are not supported at this time. If you'd like, you can create a feature suggestion for this here in our repo. Thanks :)
As far as I got it so far, OData is more meant to consume data, i.e. in a read-only manner. I want to ask whether it's intended to use OData to invoke remote functions, for example a Domain Service's method.
When looking at the OData 4.0 spec, chapter 4.3 "Addressing Entities", there are indeed terminologies like actionCall, entityFunctionCall etc. But this so far is of course also only meant for "serving", I assume.
I'd like to do something like http://example.org/service/BankAccountDomainService/ApproveBankAccount(abcde-123456)... Does that make sense?
If I understand you correctlu, you want to invoke an unbound action, which is called "Action Import" since your action "ApproveBankAccount" does not bounded to any type....
According to the Odata Protocol, the folloding URL should be "POST": the "Account" should be included in Payload.
URL: http://example.org/service/BankAccountDomainService/ApproveBankAccount()
Payload: { abcde-123456 }
Aternatively, you can also design bounded action "Approve" on entity type "BankAccount", the posted URL should be:
http://example.org/service/BankAccountDomainService/BankAccount(abcde-12345)/NameSpace.Approve()
OData is a standardized protocol for creating and consuming data APIs. OData builds on core protocols like HTTP and commonly accepted methodologies like REST. The result is a uniform way to expose full-featured data APIs.
Except providing functions and actions bound to entities, OData also provides service level functions and actions.
Please reference this URL for the sample:
https://aspnet.codeplex.com/SourceControl/latest#Samples/WebApi/ODataActionsSample/
But it is based on OData v3, and there will soon be samples for OData v4.
The Problem
I'm aware of the basic way to create a route/endpoint in ServiceStack using methods with names like "Get", "Post", "Any", etc inside a service but in the particular case that I'm trying to work with I have an existing service (which I can make an IService via inheritance) that can not be retrofitted w/ServiceStack attributes and currently uses DTOs for the requests and responses.
This service contains many functions that I do not want to manually mask (as this is a pass-through layer) but otherwise already conform to ServiceStack's requirements. What I'm wondering is if there's a way to manually create these routes in a way that would work like I've mocked up here. My existing functions and DTOs already contain the information I would need to define the routes so if this approach is possible it would only require me to enumerate them at initialization time as opposed to generating the services layer manually.
I noticed there is an extension method on Routes.Add that takes an Expression of type Expression> but I was not able to get that working because I believe the underlying code makes assumptions about the type of Expression generated (LambdaExpression vs MemberExpression or something like that). I also may be barking up the wrong tree if that's not the intended purpose of that function but I can not find documentation anywhere on how that variant is supposed to work.
Why?
I'm not sure this is necessary but to shed some light on why I want to do this as opposed to retrofitting my existing layers: The current code is also used outside of a web service context and is consumed by other code internally. Retrofitting ServiceStack in to this layer would make every place that consumes it require ServiceStack's assemblies and be aware of the web service which is a concern I want separated from the lower code. We were previously using MVC/WCF to accomplish this goal but we want some of the features available from ServiceStack.
the current architecture looks like this:
data -> DAL -> discrete business logic -> composition -> web service
Hopefully that makes enough sense and I'm not being obtuse. If you would like any more details about what I want to do or why I'll try to update this post as soon as possible.
Thanks!
You might use the fallback route in order to provide your own routing mechanism.
Then you get the request.Path property and route using your own mapping of path:Function which can be stored in a simple dictionary.
Anyway, if you go this path I don't see much benefit in using servicestack. It seems you just need an http handler that routes requests to existing services.