on 03-06-2015 9:16 AM
Hi,
with the latest work manager running on SMP3 SP6 we experience issues on displaying properties by rule on ipad.
Using an update rule to display an address property by selecting the first or last object in the collection works fine.
The below rule displays “City (Postal code)”
Using an update rule to display an address property by selecting the object in the collection with type “Customer” returns nothing.
We use the standard rule that was built in the out of the box agentry application (FindCustomerAddress).
The below rule displays “()”
If you are using SMP 3 SP06, you can use the the WPF client do debug both rules to see the return values.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I tried all contexts like suggested by Mark, without success.
With WPF debugging i got "unknown property" for the type address property.
This is a common error on ipad.
example:
Customer name and status are part of the same workorder object.The properties both get filled up when analyzing with the ATE.
When displaying on ipad, only status (and some other workorder properties) get displayed, customer name is nil. It doesn’t matter where we use the field or how we try to display it (with the object property of the field, or an update rule) it stays blank..
First row configuration
Second row configuration
Result: first row displays nothing, second row only the “test” string and the status property
Logging for the previous mentioned findcustomeraddress rule, property unknown..
2015/03/10 09:54:40.309: + Rule=A_ClientAddress_UpdateRule_Copy1
2015/03/10 09:54:40.309: + Property=:>"WorkOrderTileView" Screen Set>Current Object>"WorkOrder" Object>"Addresses" Property>First Object Where Rule "This rule serves as the Update Rule for the "Address" Field in the "WorkOrderTileView_Detail_iPad" Detail Screen in the "WorkOrderTileView" Screen Set.
RETURNS
- the new value for the Field" is True>"StreetName" Property
2015/03/10 09:54:40.309: + Rule=FindCustomerAddress2
2015/03/10 09:54:40.309: + Function=@OBJTYPE
2015/03/10 09:54:40.309: + Function=@COLLECTION_FIND_BY_STR
2015/03/10 09:54:40.309: + Property=:>"WorkOrderTileView" Screen Set>Current Object>"WorkOrder" Object>"Addresses" Property
2015/03/10 09:54:40.309: Result<Property>= "Addresses"
2015/03/10 09:54:40.355: + ConstantTerm=Customer
2015/03/10 09:54:40.355: Result<String>= 'Customer'
2015/03/10 09:54:40.355: + Property=:>"Type" Property
2015/03/10 09:54:40.355: Result<Property>= "Type"
2015/03/10 09:54:40.355: Result<Property>= <Unknown Property>
2015/03/10 09:54:40.355: Result<Boolean>= false
2015/03/10 09:54:40.355: Result<Boolean>= false
2015/03/10 09:54:40.355: Result<String>= ''
2015/03/10 09:54:40.355: Result<String>= ''
That doesn't work, I've tried every approach/context.
The odd thing is that a property that is on the same level as customer name (e.g. status) gets displayed and the customer name doesn't.
Example:
Workorder object (how it's filled up in the ATE/WPF)
- customername property: "TMVW"
- status property: "Received"
Gets displayed on ipad:
- customername property: ""
- status property: "Received"
Dieter,
Some ideas:
Idea 1:
Due to your status property works, that is a good basis of comparison.
Try to double check if you have created properties on both object and transaction level or at least check if your status has defined a transaction property while your customer name was not setup.
Idea 2:
Due to you are using only 1 update rule technique: @CONCATENATE. Did you try other rules that is not CONCATENATE? I want to see if this is just the object not displaying or if the "Context" of how the rule is used is not identifying your Customer value.
For example: CONCATENATE will treat each parameter as a string. "test" + Result of CustomerName (as String) + Result of Status (as String) = testCustomerNameStatus.
If your 2nd parameter data type was not properly converted to String type it will be shown as null or blank in this equation = test + noValue + Status. Hence this is your testReceived.
From your rule:
~~~~~~~~~Start~~~~~~~~~~~~~~
Property=:>"WorkOrderTileView" Screen Set>Current Object>"WorkOrder" Object>"Addresses" Property
2015/03/10 09:54:40.309: Result<Property>= "Addresses"
2015/03/10 09:54:40.355: + ConstantTerm=Customer
2015/03/10 09:54:40.355: Result<String>= 'Customer'
2015/03/10 09:54:40.355: + Property=:>"Type" Property
2015/03/10 09:54:40.355: Result<Property>= "Type"
2015/03/10 09:54:40.355: Result<Property>= <Unknown Property>
~~~~~~~~~end~~~~~~~~~~~~~~~~~~
You have Customer is not returning the proper type. It is claiming it is unknown.
It might be because of this function: COLLECTION_FIND_BY_STR (Is the return of this rule a "String" data type?) or is it part of the Agentry String function? Or is it Boolean?
In Concatenate, a String + a String equals a String. A concatenate only adds string. What if your COLLECTION_FIND_BY_STR is not a string function? Then you will get your test<blank>Status in the concatenate part.
Just some ideas.
Best Regards,
Mark Pe
SAP Senior Support Engineer
Mark,
the second issue was an example of how some properties get nil in workmanager for ipad.
Workorder-status gets displayed (with concatenate update rule, with direct property reference, ...)
Workorder-customername doesnt get displayed, every context possible has been tested.
The first issue, the address type that doesn't get found (although it exists) was due to "unknown property" in the WPF logging.
I've tried with EQSTRING rule and COLLECTION_FIND_BY_STR
yes, "A_ClientAddress_UpdateRule_Copy1" is the main issue, it searches the address with type customer.
I've tried getting the address with EQSTRING and COLLECTION_FIND_BY_STR, without success.
"A_update_KlantNaam" was an example of an update rule where I concatenate customernumber and status, to show that status is displayed, customernumber isn't.
Maybe both issues are related, that ipad loses reference to some properties..
Dieter,
Did you just confirm what I stated that you are using a rule that is not used with string?
Example:
@EQString - definition: takes 2 or more arguments, each evaluated as string and compares them for equality. If all arguments values are equal, this function Returns TRUE, if any value or values are found to be different it Returns FALSE.
Evaluation Type: Boolean.
This means it returns true or false.
So if you use EQString it will return true or false on your rule. It will not return the value as a string for concatenate to work.
~~~~~~~~~~~~~~start~~~~~~~~~~~~~~~~~~~
From the Agentry Rules manual (Context of Rules - Chapter 2 - Old Syclo manual):
Converting to Strings:
By and large, converting from any other data type to a string is considered the safest conversion that can be performed. In most cases, the value of the source type will be converted to a string without the loss of any values due to truncation or other concerns with conversion. There are however, some exception to this.
Following is a list of handful data types that should not be converted to the string data type:
Conversion to the collection, signature, external data and object data types should rarely, if ever, be performed. These data types are specific to certain usages and as a result, should not be converted to another data type or from another data type.
~~~~~~~~~~~~~end of document~~~~~~~~~~~~~~
Hope this helps.
Mark Pe
SAP Senior Support Engineer
Mark,
i used 2 methods to get the correct address by type customer.
The first method was by getting the correct property using "find first object where rule... is true"
the FindCustomerAddress in the picture above is a rule that returns a bool and is in the standard application:
The second method was to find the correct address object with the COLLECTION_FIND_BY_STR.
This was the rule that I've showed you the logs for..
We've solved the issue.
Problem was the mapping of some relationships on customer/partner level.
Apparently in the java middleware the mapping of these relationships is hard-coded set to english values, while we are using the dutch language.
The ATE 'picture' of the object values (customer name, customer address, ... got filled up correctly) was 2 weeks old.
In the mean time we've added some SAP notes, upgraded from SMP SP5 to SP6.
We don't know how this language issue crawled in our system, but we've changed the java to point to our dutch values.
Did it work in older version? If you have not tested in older version to verify if it is an issue then the rule may just needs to be reworked.
Rules not working is something with the Context of your properties of how you defined it in the update rule.
For example: Let MainObject be the focal point all the time.
MainObject
|__Object1 (Collection)
|___Sub-Object (Collection)
|___Property = Foo <-- Display this when Property2 = ABC
|___Propert2 = ABC
The rule or the system needs to know where your context is (from what is current - is it top down or bottom up).
If you look at most of the update rule in the out of the box code, like you said above, try to see where the "focus" is or the "context" is on how it was applied with the hierarchy from MainObject. That is how you will get it to work or how you would debug why it is not working.
Hope this generic statement or fundamental helps you out. In short in all your example from the out of the box, see how it relates to MainObject (look at the properties of mainobject - which one are collection and which one are standard properties).
Workaround:
Some technique people used is to force a top level property to hold the values you want from MainObject.
MainObject:
|___Object1 (collection)
|__PropertyX <-- a temp holder on what you can pre-populate from the MainObject.
With using Update rule now it is much easier to force an update with the top level is where the context is.
Regards,
Mark Pe
SAP Senior Support Engineer (mobility)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.