I could not understand the exact difference between Yang action vs Yang rpc and as well the difference between anydata vs anyxml. Why someone should model using anydata or anyxml? I tried finding more information about this, but I could not find. Any information on this is very helpful.
"rpc" vs. "action"
The difference between an "rpc" and an "action" is that the latter is attached to a specific data node. This node may serve as metadata for the operation to be performed.
The difference between an action and an rpc is that an action is tied
to a node in the datastore, whereas an rpc is not. When an action is
invoked, the node in the datastore is specified along with the name
of the action and the input parameters.
RFC7950, Section 7.15
Suppose you have an array of items, each of which supports individual operations, such as "start", "stop" and "restart". When someone performs such an operation, they are saying something like: "Hey, please restart this specific item instance only". You would model this in YANG 1.1 using a "list" with embedded actions. That way when the operation is performed the server knows exactly which instance you want restarted, stopped or started, since its unique identifier becomes an integral part of the <rpc> payload (or a RESTCONF operation payload).
RFC7950 uses a "server farm" example to demonstrate this. Each server in the farm may be reset.
module example-server-farm {
yang-version 1.1;
namespace "urn:example:server-farm";
prefix "sfarm";
import ietf-yang-types {
prefix "yang";
}
list server {
key name;
leaf name {
type string;
}
action reset {
input {
leaf reset-at {
type yang:date-and-time;
mandatory true;
}
}
output {
leaf reset-finished-at {
type yang:date-and-time;
mandatory true;
}
}
}
}
}
The matching NETCONF payload followed by a RESTCONF payload ("Hey, please reset 'apache-1' server"):
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<server xmlns="urn:example:server-farm">
<name>apache-1</name>
<reset>
<reset-at>2014-07-29T13:42:00Z</reset-at>
</reset>
</server>
</action>
</rpc>
POST /restconf/data/example-server-farm:server=apache-1/reset HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<input xmlns="urn:example:server-farm">
<reset-at>2014-07-29T13:42:00Z</reset-at>
</input>
Note the difference in payload encoding. For NETCONF, the <rpc> for actions contains an <action> element in the standard urn:ietf:params:xml:ns:yang:1 namespace followed by an element branch identifying the data node instance, for RESTONF there is /restconf/data instead of /restconf/operations preceding the URI.
In comparison, rpcs are "globals". They always appear at top-level of a YANG module and may or may not apply to the entire device. You could of course implement any action using an rpc statement, but that would require some non-standard way to supply the referenced data node in an argument to the operation with the "input" statement. Someone is also more likely to perform this operation on non-existent instances.
So, the real reason for introducing this statement was convenience. A lot of server implementations relied own YANG extensions to support the same behavior, so it made sense to create a real YANG keyword to define it in a standard way.
"anyxml" vs. "anydata"
The newer keyword has now become the preferred way to model a blob of arbitrary data.
It should be noted that in YANG version 1, "anyxml" was the only
statement that could model an unknown hierarchy of data. In many
cases, this unknown hierarchy of data is actually modeled in YANG,
but the specific YANG data model is not known at design time. In
these situations, it is RECOMMENDED to use "anydata" (Section 7.10)
instead of "anyxml".
RFC7950, Section 7.11
When RFC6020 was published, YANG modeled data could only be encoded in XML. It made sense to introduce a keyword that represents a blob of arbitrary well-formed XML. But with time, new encodings popped up, such as the JSON encoding used in RESTCONF.
"anyxml" now makes much less sense. Why would a JSON oriented device need to embed XML in its payloads? That is way too cumbersome. So "anydata" was introduced - it models a blob of encoding-agnostic data. If the server is using XML it will be encoded as XML, if JSON is used it will be encoded in JSON, if X is used it will be encoded in X. The only constraint on this data is that it may be modeled with YANG!
The "anydata" statement is used to represent an unknown set of nodes
that can be modeled with YANG, except anyxml, but for which the data
model is not known at module design time. It is possible, though not
required, for the data model for anydata content to become known
through protocol signaling or other means that are outside the scope
of this document.
RFC7950, Section 7.10
I'm using WsdlPull library to parse the WSDL file.
Is it possible to provide relative path in the schemaLocation whiling importing external XSD inside WSDL?
e.g.
<types>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://myprovider/namespace1/namespace1" schemaLocation="schema1.xsd"/>
</schema>
</types>
Schemas should be resolved relative to the containing document (in this case the WSDL's Url), so this should work. In fact we have WSDL files that do exactly what you appear to be trying to do.
However the implementation is given quite a lot of freedom during the resolution process (for example allowing it to transform the url causing it to load from a cache rather than the actual url).
As your positing this I assume this is not working?
I have defined my service on the WSDL file this way:
<wsdl:service name="guestbook">
<wsdl:port binding="tns:guestbookSOAP" name="guestbookSOAP">
<soap:address location="http://localhost:8080/soapguestbook"/>
</wsdl:port>
Still I am getting the following error message when running wsimport on it:
At least one WSDL with at least one service definition needs to be provided.
Is there anything else I need to add?
The problem in your case is that the definitions element is missing, which is like a root.
WSDL has a specific structure, for which the root element should be the DEFINITIONs, under it various other elements are present like types, messages, portType, binding, services etc.
The structure is like the below:
<definitions>
<types> data type definitions........ </types>
<message> definition of the data being communicated.... </message>
<portType> set of operations...... </portType>
<binding> protocol and data format specification.... </binding>
</definitions>
For the meaning of each WSDL element look into the link:
https://www.w3schools.com/xml/xml_wsdl.asp
I am trying to invoke a WebService through SOAP using Erlang and YAWS (yaws_soap_lib module specifically). The examples published on http://yaws.hyber.org/soap_intro.yaws work for me.
However, when trying to invoke my own web service YAWS fails. The first problem were partner links in the WSDL that were put there because of BPEL is befind this service. I deleted them (for now).
Unfortunately, I've come across another problem: mentioned WSDL has an empty <types> tag. Now, I am not very familiar with WSDL specification and SOAP so my question is whether it is
Erlang SOAP library issue that cannot handle empty <types> tag or
badly generated WSDL?
Does anyone know any better Erlang library for handling SOAP? I have taken a look at erlsoap but it does not support WSDLs.
EDIT: error caused by mentioned WSDL:
::error:function_clause
in function erlsom_add:add_model/2
called as add_model({model,[{type,'_document',sequence,
[{el,[{alt,'soap:Envelope','soap:Envelope',...},
{alt,'soap:Header',...},
{alt,...},
{...}],
1,1,1}],
[],undefined,undefined,1,1,1,false,...},
{type,'soap:detail',sequence,
[{el,[{alt,'#any',...},{alt,...},{...}|...],0,unbound,1}],
[],
{anyAttr,"lax","##any",[...]},
undefined,2,1,1,...},
{type,'soap:Fault',sequence,
[{el,[{alt,...}],1,1,...},
{el,[{...}],1,...},
{el,[...],...},
{el,...}],
[],undefined,undefined,5,1,...},
{type,'soap:Body',sequence,
[{el,[{...}|...],0,...}],
[],
{anyAttr,[...],...},
undefined,2,...},
{type,'soap:Header',sequence,
[{el,[...],...}],
[],
{anyAttr,...},
undefined,...},
{type,'soap:Envelope',sequence,[{el,...},{...}|...],[],{...},...}],
[{ns,"http://schemas.xmlsoap.org/soap/envelope/","soap"},
{ns,"http://www.w3.org/2001/XMLSchema","xsd"}],
"http://schemas.xmlsoap.org/soap/envelope/",[]},undefined)
in call from yaws_soap_lib:initModel2/5
For those who are familiar with the source code: The problem is the Xsds array returned by getXsdsFromWsdl function is empty.
My XML schema fu is a bit rusty, but as far as I can see the schema permits empty <types/> elements. That would suggest the first alternative, though it's hard to be sure. What error message do you get?
I would guess given the function clause error that erlsom is not handling some particular function input as being undefined. But I assume you've already validated your WSDL to make sure it's OK? Also, any chance of posting the WSDL somewhere so we can see it?
The issue has been resolved in latest YAWS version. In order to construct mentioned WSDL model following command has to be invoked:
yaws_soap_lib:initModel(WSDL_FILE_URL, [{include_fun, {erlsom_lib, find_xsd}}])
I'm using Filemaker 11 to manage content over Custom Web publishing, with a json xslt sheet to convert the XML to a json format is there any way to add a parameter to the url, and have it come back down without modifying it?
I thought about globals, but from what I can tell if two requests were sent within a short enough amount of time, there could be a race condition, one overwriting the others global..
Parameters are passed to the stylesheet in <xsl:param name="request-query" />, whose structure must be specified in the documentation, but as far as I remember it's
<query action="..."> <-- the form action, i.e. the url -->
<parameter name="...">...</parameter>
</query>
The query namespace is http://www.filemaker.com/xml/query. FileMaker's own idea of passing custom parameters is to name them like token.1, etc., but it's possible to pass just any set of parameters to a XSLT that uses a process action (i.e. doesn't hit the database), sort the parameters out into what goes into the db and what stays, make an inline call, and then process the result and add the saved parameters back.
Note that you also can access the cookies and the headers, if you need. Also note that XSLT API is deprecated and won't be supported in future FileMaker version.