10-04-2010 12:30 AM
I have a strange error with sData throwing an HTTP 500 error when accessing the Opportunities resource. This is occurring out-of-the-box with the demo database and has been reproduced by an associate on a completely different server. The problem isn't that it's a 500 error, the problem is that it's doing something that it shouldn't (I think). But, first, the calling command and the part of the error that is confusing (the whole error is below):
No row with the given identifier exists[Sage.SalesLogix.Entities.Account#AA2EK0014415]
This is particularly strange, as the account does in fact exist but should not be shown for the logged in user (demodb: derek). If requesting the record directly from the accounts resource [../-/accounts('AA2EK0014415')] throws the proper HTTP 410 error meaning (resource gone, no forwarding address).
From my understanding, the 'opportunities' resource should be similar to that of 'contacts' or 'accounts', in that only the records for which the user has access should be displayed. When I access the accounts resource for the derek user, I get a small subset of the total database. With that in mind, I've tried to control the data being returned by using the 'include' command for the 'accounts' resource:
Theoretically this command should not bring back any accounts that the user should have no access to (if my theory of sData controlling the return by security rights is correct). Instead, I get the same error. It's simply the inclusion of 'opportunities' that has this issue.
Trying this for other user logins, I get similar results. Some users with rights to all the records in the database (admin, lois, samantha) have no issues. But, as soon as I log in as another user who recieves only a subset, I get an error. And, it's not always for the same AccountId. Furthermore, the integrity checker has been run and there are no outstanding errors.
To make things even more complicated, the about 1% of the time in my testing would it actually work. Subsequent query, identical to the one that worked would fail. And, I cannot make it work consistently in any way. (Other resources also throw errors, but I'm not sure I understand how they should work for a non-admin, so I haven't tried to debug commonalities -- for example OwnerRights also errors with unknown row ...Security.Owner#ADMIN, or Processes for an unknown but existing contact).
The entire error is below:
SLX version 7.5.2. Server: Windows 2003.
Demo server is open, if anyone wants to take a look. No passwords for admin and derek. It's restored automatically every night, so feel free to do a little testing, if you have the time or inclination.
Thanks in advance!
Exception caught during the processing of a message
Original Message: No row with the given identifier exists[Sage.SalesLogix.Entities.Account#AA2EK0014415]
Stack Trace: bei NHibernate.Impl.SessionFactoryImpl.DefaultEntityNotFoundDelegate.HandleEntityNotFound(String entityName, Object id)
bei Sage.Platform.ChangeManagement.ChangeSet.UnwrapComponent(Object component)
bei Sage.Platform.ChangeManagement.ChangeSet.IncludeEntity(IPersistentEntity entity)
bei Sage.SalesLogix.Orm.EntityBase.ActivateRelatedEntity(Object entity)
bei Sage.SalesLogix.Entities.Opportunity.get_Reseller() in c:\Dokumente und Einstellungen\Administrator.ACT9SERVER\Anwendungsdaten\Sage\Platform\Output\implementation\Opportunity.cs:Zeile 1805.
bei Sage.Integration.Entity.Adapter.OpportunityRequest.CopyEntityToFeedEntry(IOpportunity entity, Opportunity entry, InclusionNode include) in c:\Dokumente und Einstellungen\Administrator.ACT9SERVER\Anwendungsdaten\Sage\Platform\Output\sdata\Opportunity.cs:Zeile 880.
bei Sage.Platform.SData.Dynamic.DynamicRequestBase`3.UpdateFeedEntryFromEntity(TFeedEntry entry, TEntity entity, InclusionNode include, Boolean includeSchema, Boolean isSingleEntry)
bei Sage.Platform.SData.Dynamic.DynamicRequestBase`3.CreateFeedEntryFromEntity(TEntity entity, SDataUri uri, Boolean isSingleEntry)
bei Sage.Platform.SData.Dynamic.DynamicRequestBase`3.CreateFeedFromEntities(IEnumerable`1 entities, SDataUri uri, Int64 totalResults, Int32 startIndex, Int32 itemsPerPage)
bei Sage.Platform.SData.Dynamic.DynamicRequestBase`3.InternalGet(ISession session, IRequest request, Boolean isNested)
bei Sage.Platform.SData.Dynamic.DynamicRequestBase`3.DoGet(IRequest request)
bei Sage.Integration.Entity.Adapter.OpportunityRequest.GetOpportunities(IRequest request) in c:\Dokumente und Einstellungen\Administrator.ACT9SERVER\Anwendungsdaten\Sage\Platform\Output\sdata\Opportunity.cs:Zeile 68.
bei Invokeb0b4026611924a70892f217a83b78a85.Invoke(Object , IRequest )
bei Sage.Integration.Messaging.RequestTargetRegistration.RequestTargetInvoker.Invoke(IRequest request)
bei Sage.Integration.Messaging.Request.Process(RequestTargetInvoker invoker)
bei Sage.Integration.Messaging.MessagingService.Process(IRequest request)
Solved! Go to Solution.
10-05-2010 06:40 AM
Ok, I'm not sure how I missed this in the error message (eyes not open, maybe), but it's failing on the 'reseller' xml tag. I looked in the two opportunity.cs files that were referenced and it's the 'reseller' that is somehow killing the feed. This still doesn't make sense, as it returns the key of the reseller (an account), and the url in the complex tag, but it's not attempting to access any data from that account (perhaps sData has to verify the account's existence first?).
Normally the reseller is returned in this format:
<slx:Reseller sdata:key="AA2EK0013627" sdata:uri="http://192.168.178.100:3333/sdata/slx/dynamic/-/accounts('AA2EK0013627')" sdata:uuid="00000000-0000-0000-0000-000000000000" />
If I could simply control the payload, then I could get rid of the 'reseller' tag. But, that doesn't work. the ?select= doesn't seem to work at all and doesn't present a subset of the data, only the entire entity. And, there is no ?include!=reseller (not equal -- or something similar to tell it not to bring back the reseller tag).
Any ideas on how to limit the return value so that reseller isn't displayed? (I don't need it anyway.)
10-06-2010 10:49 AM
Solution: Upgrade to 7.5.3. It must have been a known error with 7.5.2 (sData 1.0) that they fixed in the next version. Next problem: While they fixed Opportunities, they broke Activities with 7.5.3. At least you can work around it by adding the ?exclude=enddate parameter (but that's still kind of bad).