on 07-11-2011 4:37 PM
Hi,
I am receiving the following error when I run a transaction that contains a Tag query. In my transaction I have set the tag query mode to be defined by a local property via the link editor. Then when I execute the transaction I get the following error:
"[ERROR] [TAG_QUERY_WRITE_TAG]com.sap.xmii.Illuminator.logging.LHException: Mode parameter was not found or is malformed"
I am on version 12.1.8 Build(43).
I import the project into MII 12.1.4 Build(53) and the transaction works as expected.
In the new verson of MII is there a bug utilizing the link editor to set mode? Or is there a specific way it wants the mode linked. (e.g. specific case)
Additional details:
I am trying to use the CurrentWrite mode. I have tried setting Current mode via the link editor and that isn't working either.
Any suggestions?
Thanks,
Justin
Hi Justin,
Make sure that the data connector, historian (ID), and PCo/UDS are all write enabled. I would do some testing with just the tag query template first to make sure all the permissions are in place. If it works with the Query Template and the link editor does not work in the transaction for the very same inputs, open a ticket.
Also the Mode is case sensitive.
Regards,
Mike
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Michael,
Thanks for the reply.
It isn't an issue with writeability because I am able to write tags by just using the tag query template. I also found that if I remove the link editor assignment for the tag query mode that the transaction works. This to me sounds like a bug.
I will be opening a OSS Message. I will respond to this with what is said in the OSS message.
Thanks,
Justin
I have done some more troubleshooting on this.
In the link editor of my tag query I have 258 links defined. These links are for the query server, query mode, and then tag name/values. I performed the following steps:
In Version 12.1.4 Build(53)
Import project containing the transactions
Open project in workbench
Configure TagName1 and TagValue1 transaction properties
Execute transaction
The transaction successfully completes and updates the tag I defined with the value I defined.
In Version 12.1.8 Build(43)
Import project containing the transactions (exact same project)
Open project in workbench
Execute transaction with no tag's defined
Receive "Mode parameter was not found or is malformed" error
Configure TagName1 and TagValue1 transaction properties
Execute transaction
Receive "[ERROR] [TAG_QUERY_WRITE_TAG]java.io.EOFException" error
Open Tag Query link editor (contains 258 links)
Delete all links except Server, Mode, TagName1, and TagName2
Execute transaction
The transaction successfully completes and updates the tag I defined with the value I defined.
This leads me to believe that there is some sort of link editor limit on the new version. I would like to know how large the limit is and why it was added...
Thanks.
Justin
Hi Justin,
Did you add the extra links or did they get created when you imported from the earlier version?
And if you really want to increase the number of tags (or more importantly dynamically adjust the tags to be retrieved), use the TagName property and pass in the list of Tags comma delimited (without spaces!). Don't use the indexed Tagname properties.
You may still want to put in a ticket, but check to see if it is a problem when the links are unpopulated with data.
Good luck,
Mike
Hi Mike,
All of my links are the indexed tagname and tag value properties.
We can try to use the dynamic TagName and TagValue properties. Do you know of any negative side-effects of this on Version 12.1.8 Build(43). The reason I ask is because if the dynamic TagName and TagValue properties exist, then why are there also indexed versions? Or can the indexed versions be used to access the dynamic versions?
I have updated my OSS message with the new information, to see if they know about the link editor limit and/or issue with unpopulated links
Thanks,
Justin
Hi Justin,
Yes, the indexed tagnames get populated via the general Tagnames property. I have never tried to use it with writing values, only with retrieval. I would suspect that there might be a problem dynamically naming the indexed TagValues (it may work in more recent 12.1 versions). I know it did not in 12.0 and early versions of 12.1.
If you test it, please let everyone know your results.
Thanks,
Mike
Hi,
I tried to do a simple test but found there is no TagValues property in the Tag Query. I tried to manually type the TagValues property in the link editor but received an error that the property didn't exist.
I have also found this post:
In the post Brad was asking for an efficient and performance concious way to write tags. Using the TagValues method would be best if it existed. Because it didn't exist we had to use the indexed TagValues & TagNames. We then defined a transactional property for every indexed TagValue & TagName and then passed name/value into the transaction through our BAPI. However with the recent upgrade to MII this transaction is now broke....
Thoughts
Thanks,
Justin
Hi Justin,
I suspected that dynamically specifying the indexed TagValue properties would not work. I will ask a friend of mine to take a look at this. We had a discussion some time back about this topic. He had an idea on how to do it, but I am not sure if it is in the current version or on the roadmap for some future version.
Two other thoughts have occurred to me as alternate approaches. First is to create an OLEDB connector to the historian you are working with. Then you could use an SQL Script to add the values. Second is to build a custom action block. I usually don't recommend this approach, partly because I haven't ever needed to and partly because I am not a code jockey so it would take me a while to figure it out.
Regards,
Mike
Hi Justin,
If you had the 200+ links in 12.1.4 and it worked and now it does not work in 12.1.8, go ahead and create the ticket, but make sure to upload the transaction (in a zip file, please).
I am trying to get confirmation on this, but the target would be something along the lines of : TagValue.#Repeater.CurrentItem# for dynamic linking. Please give it a try and let me know. I am remote and my Citrix session won't let me open up any transactions.
Thanks,
Mike
Hi,
I received this response from my OSS message.
Dear Customer,
Thank you for the sample project. This appears to be more of a bug
rather than a limitation. We are looking into this issue.
We will keep you updated regarding it's progress.
-
I see TagValue.1, TagValue.10, etc for my Tag Query.
I have done some playing and so far come up with the following set of links in my Tag Query link editor.
Target XPath: TAG_QUERY_WRITE_TAG.TagValue.1
Expression: String_List_To_XML_Parser_0.Output{/Rowsets/Rowset/Row[1]/Item}
Target XPath: TAG_QUERY_WRITE_TAG.TagValue.2
Expression: String_List_To_XML_Parser_0.Output{/Rowsets/Rowset/Row[2]/Item}
etc...
Doing this will allow me to change my transaction input into 2 lists, and reduce the number of transaction properties I have.
This MIGHT solve my link editor problem by cutting the number of links in half. (inputing the tag name string in the link editor, and then inputing each tag value by parsing the value string in the link editor)
However this still doesn't allow my transaction to be 100% dynamic like I want it to. Is there a way to make this more dynamic? For example do something like this...
Target XPath: TAG_QUERY_WRITE_TAG.TagValue.#index#
Expression: String_List_To_XML_Parser_0.Output{/Rowsets/Rowset/Row[#index#]/Item}
And then have #index# dynamically select the 1,2,3,4,etc.
With the purpose of this being to avoid having to enter 128 links for TagValue.
I am hoping to avoid using a repeator due to performance. But is it even possible to use a repeator to input Tag Query values without storing in a local property?
Thanks,
Justin
Hi Justin,
Use the following dynamic links instead of hard coding. It still involves a repeater, or you could use a While Loop or even a For Next loop (I think). For the While Loop program the break or the iterations as a result of the xPath expression:
String_List_To_XML_Parser_0.Output{count(/Rowsets/Rowset/Row)}
Change your target (though I have been informed this should work, I have not personally tested it)
TAG_QUERY_WRITE_TAG.TagValue.#Repeater.CurrentItem#
And change your expression to:
String_List_To_XML_Parser_0.Output{/Rowsets/Rowset/Row[#Repeater.CurrentItem#]/Item}
which will increment as you step through each row.
I hope this is clear enough. If not, let me know.
Regards,
Mike
Hi Mike,
Please correct me if I understand the logic incorrectly. But here is what I am thinking....
I have configured my transaction to have this flow:
String_List_To_XML_Sequence --> Repeater_TagValues --> TAG_QUERY_WRITE_TAG
The String_List_To_XML_Sequence would contain String_List_To_XML_Parser_TagValues & String_List_To_XML_Parser_TagNames.
With this flow the logic would say that I will be running a seperate tag query for each tag value. So if I have 100 tag values that I want to send, I will run 100 tag queries. This doesn't seem the most efficient. Also if this is how you were thinking I would configure the transaction then I could use the following links:
Target Xpath: TAG_QUERY_WRITE_TAG.TagValue.1
Expression: String_List_To_XML_Parser_TagValues.Output{/Rowsets/Rowset/Row[#Repeater_TagInput.CurrentItem#]/Item}
Target Xpath: TAG_QUERY_WRITE_TAG.TagName.1
Expression: String_List_To_XML_Parser_TagNames.Output{/Rowsets/Rowset/Row[#Repeater_TagInput.CurrentItem#]/Item}
With this configuration updating 10 tags takes 2 seconds:
[INFO] Statistics [Load = 35 ms msec, Parse = 35 ms, Execution = 2015 ms, Total = 2067 ms]
With my old configuration updating 10 tags took 700 ms. (original transaction on 12.1.4 Build (53)
[INFO] Statistics [Load = 11.137 msec, Parse = 224.113 msec, Execution = 451.78 msec, Total = 736.62 msec]
Please let me know if I interpreted your thoughts incorrectly.
-
If there is a way to utilize only 1 Tag Query, then I am not sure how the transaction flow should be configured.
Thanks for your time,
Justin
Edited by: Justin M Brown on Jul 14, 2011 7:29 PM
Edited by: Justin M Brown on Jul 14, 2011 7:33 PM
SAP has confirmed that this is a bug and a resolution will be in SP9.
They specified the workaround as follows:
"This is happening because of the numerous blank links you have
specified as part of the link editor.
You can delete all the links with blank local property values to fix
this issue."
I will be reverting back to an older version of Mii until SP9 is available.
User | Count |
---|---|
13 | |
7 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.