Delay in initial retrieving of xml data using XRM
I am using this xml query
<fetch mapping='logical'> <entity name='de_municipality'> <order attribute='de_name' ascending='true' /> <attribute name='de_municipalityid'/> <attribute name='de_name'/> </entity> </fetch>"
For the Fetch method of XRM. It is taking around 10 seconds to get the result (though there are only limited number of entities).
ResultsXml = dc.UsingService(service => (string)service.Fetch(oFetchXml.InnerXml));
This is line of code is making the delay!!!
Next time execution will give results in 120 milli seconds.
I have experimented this query with the CRM4, the delay is only 200 milli seconds for all the attempts.
Any tips or trick or analysis method will be appreciated.
I got a reply from MSDN like this...
Hi Vinu,
we made a call to Microsoft about this issue and it was confirmed to be a design problem. This shouldn't be an issue anymore with CRM 2011.
Our current workaround is to keep the web application wich consumes the DataContext alive for as long as possible, because once the Metadata is cached the call does not occur any further.
Be careful - the DataContext not only caches the Metadata but also the content itself - such as attributes and relationships. If you want to refresh these you can clear the cache partially for specific entities as described here: Empty CRM Client DataContext cache
Kind regards
Markus
Markus Wolff
Senior Software Developer CRM Systems
Gruner & Jahr & Co. KG Hamburg, Germany
Related
Edit 2
It was a Microsoft bug. My CRM updated recently and the query is now executing as expected
Server version: 9.1.0000.21041
Client version: 1.4.1144-2007.3
Edit
If it is a Microsoft bug, which looks likely thanks to Arun's research, then for future reference, my CRM versions are
Server version: 9.1.0000.20151
Client version: 1.4.1077-2007.1
Original question below
I followed the example as described in the MSDN Documentation here.
Specify a positive number that indicates the number of entity records to be returned per page. If you do not specify this parameter, the value is defaulted to the maximum limit of 5000 records.
If the number of records being retrieved is more than the specified maxPageSize value or 5000 records, nextLink attribute in the returned promise object will contain a link to retrieve the next set of entities.
However, it doesn't appear to be working for me. Here's my sample JavaScript code:
Xrm.WebApi.retrieveMultipleRecords('account', '?$select=name', 20).then
(
result => console.log(result.entities.length),
error => console.error(error.message)
);
You can see that my query doesn't include any complex filter or expand expressions
maxPageSize is 20
When I run this code, it's returning the full set of results, not limiting the page size at all:
I noticed this too, but this happens only in UCI. Whereas this issue wont be reproduced when you run the same code in classic web UI.
Probably this is a bug in MS side, pls create a ticket so they can fix it.
UCI
Classic
I want a cache that checks its own items if they are expired or not. My cache config is below:
<?xml version="1.0" encoding="UTF-8"?>
<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>subscriberinfo</cache-name>
<scheme-name>distributed-scheme</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<distributed-scheme>
<scheme-name>distributed-scheme</scheme-name>
<lease-granularity>member</lease-granularity>
<service-name>DistributedCache</service-name>
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
<init-params>
<init-param>
<param-type>String</param-type>
<param-value>rbm-shovel-pof-config.xml</param-value>
</init-param>
</init-params>
</instance>
</serializer>
<backing-map-scheme>
<local-scheme>
<unit-calculator>BINARY</unit-calculator>
<expiry-delay>24h</expiry-delay>
<flush-delay>180</flush-delay>
</local-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>
But the thing is, flush-delay can not be set. Any ideas?
Thanks
which version of Coherence do you use ?
In Coherence 3.7, the flush-delay has been removed from dtd as deprecated since version 3.5.
Flushing is just active when inserting new objects (have a look at eviction-policy) or accessing expired objects (look at expiry-delay).
Coherence deprecated the FlushDelay and related settings in 3.5. All of that work is done automatically now:
Expired items are automatically removed, and the eviction / expiry events are raised accordingly
You will never see expired data in the cache; even if you try to access it just as it expires, the expiry will occur as an event before the data access occurs
Eviction (for memory limits) is now done asynchronously, so that the "sharp edges" of the side-effects of eviction (such as event storms) are spread out across natural cycles (with the cycle length calculated based on the estimated rate of eviction)
I hope that helps.
For the sake of full disclosure, I work at Oracle. The opinions and views expressed in this post are my own, and do not necessarily reflect the opinions or views of my employer.
But the thing is, flush-delay can not be set. Any ideas?
What do you mean by this? Does the system throw errors or the expired items not getting removed from cache. Based on the configuration you have, the entry should be removed from cache after 24hours and 180seconds since last update to the entry.
As we have found a solution for Hibernate, server side loads the data very fast : less than a sec for thousands of records and more. Now the problem is on transporting data from server to browser. Two issue:
1.The datagrid always waits until the ArrayCollection is fully loaded. We overcame this by specifying :
<destination id="someAssemble">
<properties>
<use-transactions>true</use-transactions>
<source>com.assembler.SomeAssembler</source>
<scope>application</scope>
<item-class>vo.SomeVo</item-class>
<network>
<paging enabled="true" pageSize="50" />
</network>
==> the datagrid started display quickly. The problem is the server stops loading data from row 51. Is there a way to force Flex keep loading the data in the background (by config or by code )
2.If I try to load a big ArrayCollection (for example more than 20K records), it locks down the whole browser. Is it possible to load it smoothly behind the scene?
Please help! Thank you
The following report definition continues to produce no data against all accounts:
<reportDefinition xmlns="https://adwords.google.com/api/adwords/cm/v201109">
<selector>
<fields>AccountDescriptiveName</fields>
<fields>AccountId</fields>
</selector>
<reportName>1_91_123_skinny</reportName>
<reportType>ACCOUNT_PERFORMANCE_REPORT</reportType>
<dateRangeType>YESTERDAY</dateRangeType>
<downloadFormat>TSV</downloadFormat>
</reportDefinition>
I don't get any error messages. Just no data from what would seem to be a perfectly legit reportDefinition? I've been using similar ones for some time with no problems. Any ideas?
The core issue is with zero-impression behavior:
http://googleadsdeveloper.blogspot.com/2011/12/zero-impression-data-in-adwords-api.html
The ACCOUNT_PERFORMANCE_REPORT doesn't support zero-impression rows, and even if you do have impressions you'll need ensure that you request the Impressions field.
I got in trouble with creation of an all day event appointment using Exchange 2010 Web Services (EWS) .
According to existing requirements to create an All day event appointment object needs to have specified start and end time (i.e. 10/20/2011 12:00:00 AM), and also timezone.
But my application converted to use EWS instead of WebDAV sets start and end time converted to GMT (Greenwich) time which then sent to Exchange server.
Such technique worked perfectly with WebDAV.
But with EWS I get weird result: appointment spans on 3 (three) days, and is NOT All day event appointment !!!
My mailbox timezone set to Pacific Standard Time (using OWA interface), and Exchange server Date and Time also set to Pacific Standard time.
Appointment start and end times are set to “2011-10-20T07:00:00.000Z” and “2011-10-21T07:00:00.000Z” respectively.
In terms of local time these times are “10/20/2011 12:00:00 AM” and “10/21/2011 12:00:00 AM” respectively (considering Daylight Saving time).
If IsAllDayEvent property of appointment object set to False – appointment created correctly – not as All day, starts at 10/20/2011 12AM and ends at 10/21/2011 12AM, and occupies only one day – October /20/2011 in Outlook Calendar.
But If isAllDayEvent property of appointment object set to True (everything rest remains the same) – appointment starts at Oct/19/2011 9:00:00PM, ends at Oct/21/2011 9:00:00PM, and is NOT All day.
It might be that I’m doing something wrong, but based on described above following question raised for me:
does EWS support Greenwich Time for All day events?
If yes – what might be my mistakes?
I appreciate any suggestion.
Sincerely
Andrew
Ran into a similar problem where my all day event was being created from 4pm the previous day to 4pm the specified date of the all day event (I'm currently in pacific standard time -8 so appears to be a UTC bug on the exchange server side).
When calling Appointment.save, use the optional second parameter, SendInvitationsMode.SendToNone, e.g.:
a.save(new FolderId(WellKnownFolderName.Calendar),
SendInvitationsMode.SendToNone);
If you prefer XML see Envelope/Body/CreateItem/#SendMeetingInvitations:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
<soap:Header>
<t:RequestServerVersion Version="Exchange2007"></t:RequestServerVersion>
</soap:Header>
<soap:Body>
<m:CreateItem SendMeetingInvitations="SendToNone">
<m:SavedItemFolderId>
<t:DistinguishedFolderId Id="calendar"></t:DistinguishedFolderId>
</m:SavedItemFolderId>
<m:Items>
<t:CalendarItem>
<t:Subject>From Java EWS</t:Subject>
<t:Body BodyType="HTML">the body</t:Body>
<t:Start>2014-01-03T00:00:00Z</t:Start>
<t:End>2014-01-04T00:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>
</t:CalendarItem>
</m:Items>
</m:CreateItem>
</soap:Body>
</soap:Envelope>
In addition to Pete's answer:Note that there is a difference between what Exchange has stored and what Outlook tells you. I'm writing 'pure' SOAP XML calls to an Exchange 2010 Server calendar and viewing the results through Outlook 2003. The creation calls explicitly specify UTC times and have no other time zone information. The server has UTC settings.
If I now create an allday event like this:
<mes:CreateItem SendMeetingInvitations="SendToNone">
<mes:Items>
<typ:CalendarItem>
<typ:Subject>Alldayevent</typ:Subject>
<typ:Start>2013-01-08T01:00:00.000Z</typ:Start>
<typ:End>2013-01-08T02:00:00.000Z</typ:End>
<typ:IsAllDayEvent>true</typ:IsAllDayEvent>
... Exchange correctly stores this as (GetItem output):
<t:Start>2013-01-08T00:00:00Z</t:Start>
<t:End>2013-01-09T00:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>
If Outlook is also configured for UTC this shows as an all day event for 8. January (as expected).
However, if I set Outlook to UTC+1 (Amsterdam time), the event is displayed extending over two days (and note he checkbox being blank):
Checking 'All day' in that situation results in (GetItem output):
<t:Start>2013-01-07T23:00:00Z</t:Start>
<t:End>2013-01-09T23:00:00Z</t:End>
<t:IsAllDayEvent>true</t:IsAllDayEvent>
I'm doing a DAV to EWS conversion myself. Something that might be of interest I ran across from Best Practices for Using Exchange Web Services for Calendaring Tasks (Ex 2007, but I assume applies to Exchange 2010 and 2013)
When Exchange Web Services receives a request to create a new CalendarItem for which the start and End properties are identified by non-UTC-offset strings, the server must convert the Start and End properties to Coordinated Universal Time (UTC) before the CalendarItem can be stored. The following are the rules for the conversion to UTC:
If the request contains an explicit time zone definition via a MeetingTimeZone property, the server will apply the correct offset with regard to Standard and Daylight rules as defined by the time zone.
If no explicit time zone is defined, the current time zone of the computer that is running Exchange 2007 (specifically, the Client Access server that is processing the request) will be used.
Note:
In Exchange 2007 SP1, all unspecified time zones are set to UTC instead of the time zone of the Client Access server.
Experimenting a little bit, I found that if you do not specify a timezone, EWS will indeed apply the time as UTC. If IsAllDayEvent is true start times and end are ignored besides their date component. So an all day event turns into 12:00am-12:00am UTC or 5:00pm-5:00pm on my calendar (I'm -7 UTC also). The Best Practices article recommends using the MeetingTimeZone element, but I received an error that it was depreciated, use StartTimeZone and EndTimeZone instead. Indeed adding <StartTimeZone Id="Pacific Standard Time"> seems to work.
As far as your 3 day issue goes I was able to reproduce similar results. Here is what I suspect is happening. If you tell Exchange the start time is 7am and end time is 8am, and flag it all day, it will automatically set the start and end times to yyy-mm-ddT00:00:00 and yyy-mm-dd+1T00:00:00. So if I send an appointment for 2011-11-04T07:00:00 to 2011-11-05T07:00:00 w/o the timezone element, it thinks I'm trying to span two days. The start time 2011-11-04T07:00:00 becomes 2011-11-04T00:00:00 to 2011-11-05T00:00:00. The end time 2011-11-05T07:00:00 becomes becomes 2011-11-05T00:00:00 to 2011-11-06T00:00:00. This gets thrown on the calendar as UTC. When viewed it in Outlook or in webapp it displays it in PST as Nov 3rd 5pm - Nov 6th 5pm and looks like its spanning 3 days (but only actually only 48 hours).
You need to specified MeetingTimeZone(for ES2007) or StartTimeZone(for ES2010+). I had the same problem, and it helped me.