I was wondering if there is any possible way, to get the names of all the functions, which a deployed Chaincode contains, along with the arguments each of them expects, as well as their return-types.
So that the client application can utilize it to minimize inconsistencies while calling them.
You can use one of the Fabric SDKs (e.g Node SDK) to submit a transaction with the argument 'org.hyperledger.fabric:GetMetadata'.
This will return a buffer containing your smart contract metadata, which will have information about your transactions, their arguments, etc.
Related
Spring Cloud Gateway appears to be reordering my query parameters to put duplicate parameters together.
I'm trying to route some requests to one of our end points to a third party system. These requests include some query parameters that need to be in a specific order (including some duplicate parameters), or the third party system returns a 500 error, but upon receiving the initial request with the parameters in the proper order, the Spring Cloud Gateway reorders these parameters to put the duplicates together by the first instance of the parameter.
Example:
http://some-url.com/a/path/here?foo=bar&anotherParam=paramValue2&aThirdParam=paramValue3&foo=bar
Becomes:
http://some-url.com/a/path/here?foo=bar&foo=bar&anotherParam=paramValue2&aThirdParam=paramValue3
Where the last parameter was moved to be by the first parameter because they had the same name.
The actual request output I need is for the query parameters to be passed through without change.
The issue lays in the UriComponentsBuilder which is used in RouteToRequestFilter.
UriComponentsBuilder.fromUri(uri) is going to build up a map of query params. Because this is a LinkedMultiValueMap you see the reordering of the used query params.
Note that RFC3986 contains the following
The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI’s scheme and naming authority (if any).
Therefor I don’t think there needs to be a fix in Spring Cloud Gateway.
In order to fix this in your gateway, you'll need to add a custom filter which kicks in after the RouteToRequestFilter by setting the order to RouteToRequestUrlFilter.ROUTE_TO_URL_FILTER_ORDER + 1.
Take a look at the RouteToRequestUrlFilter how the exchange is adapted to go to the downstream URI.
Hope that helps! :)
A customer has implemented an OPC-UA server and has provided some documentation for us to access it. The only information we have is the endpoint to contact the server at and the tags that the data points are linked to.
I have to implement a client without having access to the server to test it with. Is this enough information to go by? I imagine we would at least need some namespace uri. From what I understand, in order to use a function such as translateBrowsePathsToNodeIds I would also need to know some namespace ID's.
For instance, in python-opcua it would be something like:
mynode = client.uaclient.translate_browsepaths_to_nodeids(ua.QualifiedName("StaticData", 3)) (which somehow is not working but that's another question)
It doesn't help that the client examples I find somehow all use hardcoded namespace ID's.
TranslateBrowsePathToNodeIds is generally used when programming against type definitions where you know what the path of BrowseNames will be because they are defined by the type definition of each node in the path.
If this doesn't sound like your situation then you should push back for the documentation to include the NodeIds of all the Nodes you need to access.
Building an pagination API. Assume the request is coming for 0 to 5 resources.
The API returns the 5 resources in an order.
But there is no explicit sequence number or order in the responses.
When the data is transferred in a network, will the list ensures the order while the data is served from service to app?
My worries are Service will be in some technology stack - java/node-js etc., The client can be java based android app, js based react native app, another backend service in java/node-js.
Each one will have own serialization and deserialization libraries. Will it be consistent in order the elements.
I am thinking of adding explicit sequence number/index values, explicitly tell the clients to use sequence number/index values for any ordering/sorting based operations.
Is my understanding correct?
Does explicit sequence number needed or not?
Does the serialization and de-serialization library maintains the order?
to be sure to get the order you want, you could achieve it in one line if sort text object:
arrayResults.sort((a, b)=> b.titleObject.toUpperCase().localeCompare(a.titleObject.toUpperCase()))
sort number:
arrayResults.sort((a, b)=> b.numberObject - a.numberObject)
Then you could paginate peacefully
I was wondering what others are doing to expose REST api endpoints with the datastore (using app engine standard). I want to use urlsafe keys but 1 - I'd rather not pass this data directly as it poses a security risk since app-engine to app-engine calls are exposed over a public ip, and 2 - the keys that are generated are very long and would not be great when multiple need to be passed as a query parameter to form a get request (and would probably exceed browser character limits).
I was thinking maybe using compression of some sort to compress the urlsafe keys which would solve both 1 and 2, but want to see if there is a better way to create REST endpoints. Or if some type of compression method is already baked into ndb?
Google uses HTTPS internally so I'm not sure you need to worry about it.
Also, you should probably design your app so that keys are not secret info and such that it is safe to expose them.
I use key IDs for my REST calls, which I believe are 12 digit numbers. That works as long as you know the entity type. If you need to specify the entity type, you could add another parameter to your API call.
we have two distinct jax-ws #WebServices with different target namespaces. however, these two services each declare a single #WebMethod with same name, but different parameter types (which in both cases is a single custom java class). we deploy them to websphere servers and have our WSDL/XSD generated dynamically.
apparently, we end up with two sets of WSDL/XSD where we have different ports, different namespaces for everything, but same operation name and same request/response type names and element names (again, namespaces are different).
when we call these webservices, one of them works, the other is not able to unmarshall the message because it magically expects the request type from the first one, which is clearly said in the exception that we receive.
i was able to reproduce this locally, using only jaxb and the issue appears to be as follows: SOAP messages like "soap:Body/ns1:request1" and "soap:Body/ns2:request1" somehow conflict with eachother when they are unmarshalled within the same JAXBContext and the one jaxb-annotated class referenced last wins.
WSDL spec says nothing about this (as ports are different), and even the internet doesn't know about this too much at all, so i wonder if there's something really wrong with what we do. common sense suggests this must be entirely possible.
the issue is very similar to this [unanswered] post: http://www.coderanch.com/t/463070/Web-Services/java/method-classes-conflict. and is exactly the same as this [unanswered really] post: Jaxb objects with same name (the guy doesn't really explain, why this style of doing things is not recommended).
the question really is: is it possible to declare two jax-ws services with methods having same names but different arguments and then deploy them in one web application?