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
Related
What is the difference between reading the properties from payload. for example there is a property in the payload which is named as con_id. when i read this property like this #[payload.con_id] then it is coming as null. where as #[payload.'con_id'] is returning the value.
few other notations which i know of is #[payload['con_id']] or #[json:con_id]
which one should be used at which scenario? if there are any special cases to use any specific notation then please let me know the scenario also.
Also, what is the common notation that has to be used from a mule soft platform supported point of view.
In Mule 3 any of those syntax are valid. Except the json: evaluator is for querying json documents where as the others are for querying maps/objects. Also the json: evaluator is deprecated in Mule 3 in favor of transforming to a map and using the MEL expressions below.
payload.property
payload.'property'
payload['property']
The reason the first fails in your case, is beacaue of the special character '_'. The underscore forces the field name to be wrapped in quotes.
Typically the . notation is preferred over the [''] as its shorter for accessing map fields. And then simply wrap property names in '' for any fields with special chars.
Note in Mule 4, you don't need to transform to a map/object first. Dataweave expression replace MEL as the expression language and allow you to directly query json or any type of payload without transforming to a map first.
We are writing a tool in Java that parses and transforms ABAP code. We therefore have no intention to write new ABAP code but our tool has to handle all of ABAP, even obsolete statements. Furthermore, I'm not an ABAP expert.
ABAP programs can use type groups, introduced by key word TYPE-POOL. Names of type groups have a maximal length of five (internally eight, if you count the prefix "% C"), their type code is TYPP. In the past, relying on these assumptions worked well for us.
Recently, we see ABAP programs with type code TYPP but with name longer than 5, e.g., 'OIA===========================P'. Furthermore, for each of those, there is another, empty object with same name but type code INCL. These new objects are referenced only if a regular type group is, too.
These new objects may be internal ones and irrelevant for us - I haven't seen any reference to them in the ABAP Keyword Documentation. On the other hand, they are confusing us because we see them.
Can someone explain to me the meaning of these objects and point me to some documentation?
Edit: Here examples from an EHP7 for SAP ERP 6.0 system
An example object. Entries in D010INC look fine:
The same object now using type pool mrm. Where do the additional includes come from?
These objects are introduced through inclusions, extensions and switched objects. To read along:
Check type pool MRM, type mrm_idoc_data_ers - that type contains a statement to include rmrm_idoc_data_ers_sbo. A similar include statement pulls rmrm_upd_arseg_nfm into mrm_upd_arseg. That explains the last two lines. Your parser should have caught that.
RMRM_IDOC_DATA_ERS_SBO contains an enhancement point named RMRM_IDOC_DATA_ERS_SBO_02 that belongs to an enhancement spot ES_RMRM_IDOC_DATA_ERS_SBO. Similarly, RMRM_UPD_ARSEG_NFM contains an enhancement point RMRM_UPD_ARSEG_NFM_01 that belongs to the enhancement spot ES_RMRM_UPD_ARSEG_NFM.
For ES_RMRM_IDOC_DATA_ERS_SBO, an enhancement implementation named ISAUTO_MRM_RMRM_IDOC_DATA_ERS exists. For ES_RMRM_UPD_ARSEG_NFM, an implementation named /NFM/MM_RMRM_UPD_ARSEG_NFM exists. That explains the references ending with =E
The implementation ISAUTO_MRM_RMRM_IDOC_DATA_ERS is located in the package ISAUTO_MRM. The implementation /NFM/MM_RMRM_UPD_ARSEG_NFM is located in the package /NFM/MM. That explains the references ending with =P. Obviously, these references are not generated for every package:
The package ISAUTO_MRM is controlled by the switch AM_ERS, the package /NFM/MM is controlled by the switch /NFM/MM. That explains the references ending in =S.
Ultimately, these references can be used to determine which programs need to be re-generated when the state of a switch is changed.
I have a small question in my mind. I researched it on the Internet but no-one is providing the exact answer. My question is:
In data flow coverage criteria, say there is a method which finally returns variable x. When drawing the graph for that method, is that return statement considered to be a use of x?
Yes, a return statement uses the value that it returns. I couldn't find an authoritative reference that says so in plain English either, but here are two arguments:
A return statement passes control from one part of a program to another, just like a method call does. The value being returned is analogous to a function parameter. return therefore is a use just like being a function parameter is a use.
The other kind of use in data flow analysis is when a value leaves the program and has some effect on the outside world, for example by being printed. If we're analyzing a method, rather than an entire program, return causes the value to leave the scope which we're analyzing. So it's a use for the same reason that printing is a use.
I'm trying to write a upnp/dlna client for videos and I would like to allow the option to sort by title and date.
With Windows7/wmp as the server, I can use "dc:title" or "dc:date" for sorting and it seems to work but testers have told me it doesn't work on other servers. Is there a universal way to know if sorting is allowed and what the sorting criteria should be?
Thanks.
There is a way to query this (but be prepared for broken implementations that lie about their abilities as well). Quoting ContentDirectory service spec (v3):
2.3.3
SortCapabilities
This state variable is a CSV list of property names that the ContentDirectory service can use to sort
Search() or Browse() action results. An empty string indicates that the device does not support any kind of
sorting. A wildcard (“*”) indicates that the device supports sorting using all property names supported by
the ContentDirectory service. The property names returned MUST include the appropriate namespace
prefixes, except for the DIDL-Lite namespace. Properties in the DIDL-Lite namespace MUST always be
returned without the prefix. All property names MUST be fully qualified using the double colon (“::”)
syntax as defined in Section 2.2.20, “property”. For example,
“upnp:foreignMetadata::fmBody::fmURI”
I'm currently working on my first major project in clojure and have run into a question regarding coding style and the most "clojure-esque" way of doing something. Basically I have a function I'm writing which takes in a data structure and a template that the function will try to massage the data structure into. The template structure will look something like this:
{
:key1 (:string (:opt :param))
:key2 (:int (:opt :param))
:key3 (:obj (:tpl :template-structure))
:key4 (:list (:tpl :template-structure))
}
Each key is an atom that will be searched for in the given data structure, and it's value will be attempted to be matched to the type given in the template structure. So it would look for :key1 and check that it's a string, for instance. The return value would be a map that has :key1 pointing to the value from the given data structure (the function could potentially change the value depending on the options given).
In the case of :obj it takes in another template structure, and recursively calls itself on that value and the template structure, and places the result from that in the return. However, if there's an error I want that error returned directly.
Similarly for lists I want it to basically do a map of the function again, except in the case of an error which I want returned directly.
My question is what is the best way to handle these errors? Some simple exception handling would be the easiest way, but I feel that it's not the most functional way. I could try and babysit the errors all the way up the chain with tons of if statements, but that also doesn't seem very sporting. Is there something simple I'm missing or is this just an ugly problem?
You might be interested in schematic, which does pretty similar stuff. You can see how it's used in the tests, and the implementation.
Basically I defined an error function, which returns nil for correctly-formatted data, or a string describing the error. Doing it with exceptions instead would make the plumbing easier, but would make it harder to get the detailed error messages like "[person: [first_name: expected string, got integer]]".