|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Hello,
We are in the process of setting up SData on a new installation. The following has worked in the past on another installation but for some reason we cannot succeed this time.
Upon installation, accounts seems to have communicated with the SData webserver because we can see the company dataset in the list of SData companies under Internet Options.
We've opened port 5493 on the firewall..
http://server-on-domain:5493/ is reachable.
However, the following URI or similar are never loading.
http://server-on-domain:5493/sdata/accounts50/GCRM/{DatasetID}/TradingAccounts
The browser presents http authentication, but then keeps on trying to load with no response from the webserver.
The webserver is not logging anything in the event viewer for these unsucessful requests.
The only thing the sdata webserver is logging upon startup is the following exception:
Exception caught during Integration Server shutdown: Unable to locate the Type 'Sage.Integration.Server, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3f422f0ff54abde1' in the specified Assembly 'Sage.Integration.Server, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3f422f0ff54abde1' from C:\WINDOWS\assembly\GAC_MSIL\Sage.Integration.Server\1.0.0.0__3f422f0ff54abde1\Sage.Integration.Server.dll (Unregister Request Targets)
Thanks for your help
Reuben
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
What version of Accounts is this using?
From the sounds of it the communication is OK as you are getting to the feed page and the authentication is working. From the symptoms my guess would be that the issue is one of performance. How many trading accounts (customers and suppliers) are there in the dataset you are trying to connect to?
If you query for a single trading account do you get a response? To get a single trading account you can do something like this: http://server-on-domain:5493/sdata/accounts50/GCRM/{DatasetID}/TradingAccounts?count=1
Do other feeds return data? Try these feeds:
http://server-on-domain:5493/sdata/accounts50/GCRM/{DatasetID}/taxCodes
http://server-on-domain:5493/sdata/accounts50/GCRM/{DatasetID}/financialAccounts
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Accounts v18.
Around 400 trading accounts.
A single account is not loading either.
No, other feeds do not return data either.
We are running Accounts on Windows 2003. Previous installations that have worked were running in Server 2008. The choice of OS used by our client is beyond our control.
Reuben
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
Whilst not officially supported I can't think of a good reason why the Accounts 2012 Sdata feeds would not work on Server 2003.
Do they run work locally on the server e.g. http://localhost:5493/sdata/accounts50/GCRM/{DatasetID}/taxCodes ?
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Locally same problem
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
So just to confirm, after entering your username and password the browser just 'spins' waiting for a response from the server?
Has 3rd party integration been enabled from within Accounts on the server?
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
yes it just spins like that.
not sure third party integration was enabled. i will check. does it need to be enabled or is it only for sage data objects?
reuben
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
does the service log any errors somewhere? no errors are reported in Event Viewer apart from the one posted earlier.
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
Reuben Sant wrote:does the service log any errors somewhere? no errors are reported in Event Viewer apart from the one posted earlier. The Sdata service itself only writes to the event log but the Accounts adapter does maintain a separate log. Where the log is written really depends on the OS and how the service is currently configured but typically it will be in C:\Windows\System32\config\systemprofile\AppData\Roaming\SDOAdapterLogs on a 32 bit system or C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\SDOAdapterLogs on a 64 bit system. There could be a lot of noise in the logs if you've been running for a while so it might be best to stop the Sdata service, delete all the log files, restart the service and attempt to reconnect. That way you can be sure the logs will only contain information relating to initialization and the connection attempt. Whilst 3rd party integration should not need to be enabled the adapter does make use of SDO so I would not completely rule it out as being a problem. One other thought. Is the problem data specific? Do you have a different dataset that you can attempt to log on to? You can check what datasets are available by querying the end points feed e.g. http://localhost:5493/sdata/$system/registry/*/endpoints?where=contractName eq 'GCRM'.
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\SDOAdapterLogs is an empty folder
Just tried a different dataset - same problem :(
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
Reuben Sant wrote:C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\SDOAdapterLogs is an empty folder It shouldn't be. What user is the Sdata service currently configured to run as? Did you check is 3rd party integration was enabled? If it is you can check that SDO is working by running the following script: Code:Dim oSDO
set oSDO = CreateObject("SDOEngine.18")
Dim oWS
set oWS = oSDO.Workspaces.Add("Example")
' Adjust the following path to point to your data
oWS.Connect "C:\ProgramData\Sage\Accounts\2012\Company.000\ACCDATA", "MANAGER", "", "Example"
MsgBox "Connected!"
oWS.Disconnect()
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Now I can see a log file there.
I have repeated instances of these entries.. (modified "LOCAL" and "DATASET")
I[10]:[20120725100652.634]: SDORequestManager.GetRequest: GET http://LOCAL:5493/sdata/accounts50/GCRM/{DATASET}
E[10]:[20120725100652.635]: SDORequestManager.GetRequest: Unable to locate the specified object 'accounts50/GCRM/-'
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetHandler(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.OnGetResource(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetRequest(IRequest request)
I[10]:[20120725100652.635]: SDORequestManager.GetRequest: GET request complete. Request: http://LOCAL:5493/sdata/accounts50/GCRM/{DATASET}. Response: InternalServerError. FeedEntry: NULL. FeedEtries: 0. Time Taken: 0 minutes
I[10]:[20120725100700.619]: SDORequestManager.GetRequest: GET http://LOCAL:5493/sdata/accounts50/GCRM/{DATASET}/tradingAccounts
I[10]:[20120725100700.619]: RequestHandler`2.GetRequest: GetRequest: http://LOCAL:5493/sdata/accounts50/GCRM/{DATASET}/tradingAccounts
I[10]:[20120725100700.620]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 33156464
I[10]:[20120725100700.620]: SDOWorkspaceManager.GetWorkspace: No username specified. RespondUnauthorized on request 33156464
I'm sure i'm using the correct password with HTTP authentication. Same issue occurs when accessing through the API using SDataRequest. So it's not a browser issue.
With regards to SDO, I have just registered 3rd party integration, but same problem occurs.
With regards to the Server 2003 issue, I have moved the company files to a Server 2008, to a Win XP and to a Win 7. This company did not not return SData response on any machine, but the company loads well in Accounts. Other companies are working. So the issue should be related to this dataset. How can I check what's wrong with it, because the client wants to use this company of course.
Thanks and Regards
Reuben
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Noticed something else:
The reason the browser is not responding is that the SData windows service is freezing and becoming unresponsive. This happens after the first request for this company. Requests for other companies work fine. An attempt to restart the service is unsuccessful. The service does not respond to the STOP command. I have to forcefully close the process Sage.SData.Service.exe to stop the service.
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
From the log it would seem to indicate that there are no datasets available at all. Very strange. Is there any more to the log? It does look somewhat incomplete. Don't worry about the "No username specified" message. Initially there will be an unauthenticated GET request, the response to this will be 'unauthorized' which is what causes the browser to prompt for authentication. When you enter the username/password the request is resubmitted but this time with the credentials specified in which case the request will proceed (assuming the correct credentials were entered of course). I should stress that this process is just the standard challenge/response mechanism used by the web browser rather than being anything specific to Sdata or the SIF. Reuben Sant wrote:With regards to SDO, I have just registered 3rd party integration, but same problem occurs. Have you tried running the script I suggested above? This would confirm that SDO is working correctly and that it is possible to authenticate against the dataset. Reuben Sant wrote:With regards to the Server 2003 issue, I have moved the company files to a Server 2008, to a Win XP and to a Win 7. This company did not not return SData response on any machine, but the company loads well in Accounts. Other companies are working. So the issue should be related to this dataset. How can I check what's wrong with it, because the client wants to use this company of course. So, just to be clear. Are you saying that if you take a backup of the dataset and restore it on another PC that you see the same problem of the browser hanging when attempting to access the dataset via Sdata but other datasets on the same PC return the data as expected? If this is the case I might be inclined to agree that it looks like a problem with the data but you did previously say that you had the same issue with a different dataset, which would indicate a setup/configuration issue as being the more likely culprit. As that seems a little conflicting it's probably worth go back to check some of the basics: 1. What is the exact version of Accounts installed on the server (you can get this from Help -> About)? 2. What is the contents of the company file on the server? 3. What user is the Sage Sdata Service currently configured to run as on the server? 4. What is result of running the VB script from my earlier post (don't forget to adjust the data path accordingly). 5. What datasets are listed if you go to the URL http://localhost:5493/sdata/$system/registry/*/endpoints?where=contractName eq 'GCRM' on the server? 6. Can you connect to the dataset using the main Accounts application on the server? 7. Assuming you can connect as #6 are any errors or warnings highlighted if you go to File -> Maintenance -> Check Data?
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Sorry for the confusion
1. 10.0.10.208
2. Not sure what you mean. Yes the contents of the company folder are on a server. Using absolute network address not UNC path. There are 261 customers and 160 suppliers. EDIT: tried also local paths as you can see in the logs below.
3. Tried both 'Local System' and a domain 'DOMAIN\Administrator'. Same result.
4. Sorry havent tried the vbscript earlier: ActiveX component can't create object SDOEngine.18. Yes, 3rd party integration was done. I got the message Sage Data Objects was registered and under visual studio I see the registered type library under Add Reference > COM .. C:\Windows\SysWOW64\SdoEng180.tlb
5. Two datasets are listed. The one that I need (Dataset A) and a test company (Dataset B). Yes, earlier both A and B were unresponsive. But it was due to the fact that first I accessed A then B. A brings the SData windows service to a spin. It could not even be stopped. Had to terminate it forcefully. Upon service restart, I accessed B (without first accessing A), and.. success! I went back to A and.. nothing again. Yes, this might imply something wrong with dataset A.
6. Yes. Both dataset A and B. Both on the server and on a remote machine that has Accounts installed. So, no networking issues.
7. Tried that. No errors. I also tried re-indexing data files.
As for the logs, please find the latest logs below. I have changed some info to XXXX and YYYY
Thanks for your patience.
I wish we don't have to abandon SData as we already invested a significant amount of development effort.
Reuben
E[10]:[20120725120353.195]: SDORequestManager.GetRequest: Unable to locate the specified object 'accounts50/GCRM/-'
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetHandler(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.OnGetResource(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetRequest(IRequest request)
I[10]:[20120725120353.195]: SDORequestManager.GetRequest: GET request complete. Request: http://aphrodite:5493/sdata/accounts50/GCRM/{B1B8793B-EFF2-451B-AE70-XXXX}. Response: InternalServerError. FeedEntry: NULL. FeedEtries: 0. Time Taken: 5.0005E-05 minutes
I[10]:[20120725120400.696]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{B1B8793B-EFF2-451B-AE70-XXXX}/tradingAccounts
I[10]:[20120725120400.697]: RequestHandler`2.GetRequest: GetRequest: http://aphrodite:5493/sdata/accounts50/GCRM/{B1B8793B-EFF2-451B-AE70-XXXX}/tradingAccounts
I[10]:[20120725120400.697]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 42659827
I[10]:[20120725120400.697]: SDOWorkspaceManager.GetWorkspace: No username specified. RespondUnauthorized on request 42659827
I[10]:[20120725120404.325]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{B1B8793B-EFF2-451B-AE70-XXXX}/tradingAccounts
I[10]:[20120725120404.326]: RequestHandler`2.GetRequest: GetRequest: http://aphrodite:5493/sdata/accounts50/GCRM/{B1B8793B-EFF2-451B-AE70-XXXX}/tradingAccounts
I[10]:[20120725120404.326]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 40644060
I[15]:[20120725125337.041]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}
E[15]:[20120725125337.042]: SDORequestManager.GetRequest: Unable to locate the specified object 'accounts50/GCRM/-'
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetHandler(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.OnGetResource(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetRequest(IRequest request)
I[15]:[20120725125337.042]: SDORequestManager.GetRequest: GET request complete. Request: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}. Response: InternalServerError. FeedEntry: NULL. FeedEtries: 0. Time Taken: 1.66683333333333E-05 minutes
I[15]:[20120725125345.223]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}
E[15]:[20120725125345.223]: SDORequestManager.GetRequest: Unable to locate the specified object 'accounts50/GCRM/-'
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetHandler(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.OnGetResource(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetRequest(IRequest request)
I[15]:[20120725125345.223]: SDORequestManager.GetRequest: GET request complete. Request: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}. Response: InternalServerError. FeedEntry: NULL. FeedEtries: 0. Time Taken: 0 minutes
I[15]:[20120725125348.768]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[15]:[20120725125348.790]: RequestHandler`2.GetRequest: GetRequest: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[15]:[20120725125348.791]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 39458692
I[15]:[20120725125348.791]: SDOWorkspaceManager.GetWorkspace: No username specified. RespondUnauthorized on request 39458692
I[15]:[20120725125403.575]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[15]:[20120725125403.575]: RequestHandler`2.GetRequest: GetRequest: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[15]:[20120725125403.575]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 14678165
I[4]:[20120725125529.835]: SDOWorkspaceManager.LoadCompanies: Loading company list from C:\ProgramData\Sage\Accounts\2012
I[4]:[20120725125529.837]: SDOWorkspaceManager.LoadCompanies: Loaded company YYYY C:\USERS\XXXX\DESKTOP\COMPANY.000\accdata {53BDCC69-8A37-454E-A716-XXXX}
I[4]:[20120725125529.837]: SDOWorkspaceManager.LoadCompanies: Loaded company XXXX C:\USERS\XXXX\DESKTOP\accdata {B1B8793B-EFF2-451B-AE70-XXXX}
I[4]:[20120725125536.654]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}
E[4]:[20120725125537.346]: SDORequestManager.GetRequest: Unable to locate the specified object 'accounts50/GCRM/-'
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetHandler(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.OnGetResource(IRequest request)
at Sage.Integration.Accounts50.SDOAdapter.SDORequestManager.GetRequest(IRequest request)
I[4]:[20120725125537.346]: SDORequestManager.GetRequest: GET request complete. Request: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}. Response: InternalServerError. FeedEntry: NULL. FeedEtries: 0. Time Taken: 0.0115344866666667 minutes
I[4]:[20120725125541.280]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[4]:[20120725125541.314]: RequestHandler`2.GetRequest: GetRequest: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[4]:[20120725125541.328]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 18736075
I[4]:[20120725125541.329]: SDOWorkspaceManager.GetWorkspace: No username specified. RespondUnauthorized on request 18736075
I[4]:[20120725125544.422]: SDORequestManager.GetRequest: GET http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[4]:[20120725125544.422]: RequestHandler`2.GetRequest: GetRequest: http://aphrodite:5493/sdata/accounts50/GCRM/{53BDCC69-8A37-454E-A716-XXXX}/taxCodes
I[4]:[20120725125544.422]: SDOWorkspaceManager.GetWorkspace: Attempting to get workspace for request 57913258
I[4]:[20120725125544.425]: SDOWorkspaceManager.GetWorkspace: Verify request has a password (Id: {53BDCC69-8A37-454E-A716-XXXX}, User: reuben, Company: Sage.Integration.Accounts50.SDOAdapter.Feeds.Company)
I[4]:[20120725125544.428]: SDOWorkspaceManager.GetWorkspace: Check thread cache (Id: {53BDCC69-8A37-454E-A716-XXXX}, User: reuben, Company: Sage.Integration.Accounts50.SDOAdapter.Feeds.Company)
I[4]:[20120725125544.428]: SDOWorkspaceManager.GetWorkspace: Check global cache (Id: {53BDCC69-8A37-454E-A716-XXXX}, User: reuben, Company: Sage.Integration.Accounts50.SDOAdapter.Feeds.Company)
I[4]:[20120725125544.449]: SDOWorkspaceManager.GetWorkspace: Creating workspace holder for request 57913258
I[4]:[20120725125544.452]: SDOWorkspaceManager.GetWorkspace: Attempting to connect to workspace for request (Id: {53BDCC69-8A37-454E-A716-XXXX}, User: reuben, Company: Sage.Integration.Accounts50.SDOAdapter.Feeds.Company)
|
|
Rank: Advanced Member
Joined: 10/13/2010
Posts: 117
|
1. I take it you mean 14.0.10.208. This is a bit out of date with patches and there are 6 updates that have not been installed (the latest version would be 18.1.0.20). I doubt that simply being out of date is the cause of your problem but I would definitely recommend applying the updates as there have been a number of fixes and performance enhancements for the Sdata adapter included in the updates.
2. There is a file called COMPANY (it has no file extension) stored in C:\ProgramData\Sage\Accounts\2012. It's actually just a text file and can be opened in Notepad for viewing. The file will contain a list of paths to data that Accounts 'knows' about.
3. I'm tending to think that it's not a permissions issue but the main thing to check would be that whatever user the service is configured to run as has read/write access to and data path specified in the company file (see #2). Bear in mind that even when logged on with the administrator account it still might not have permissions by default - uncommon but possible. It might be worth reapplying the permissions to the data folder(s) just to be sure.
4. That would normally ring alarm bells were it not for your response to #5.
5. Great. That proves that the setup and configuration is OK and that we are pretty conclusively looking an issue with the data.
6 & 7. Because you can access the data from the main Accounts application and there are no reported errors I can only think that it could be one of two possibilities. Either the Sdata service user cannot access the data path (as noted in #3 I think this is unlikely but worth checking anyway) or there is a very subtle data corruption issue with the data that is not being picked up by the check data routines of the Accounts application. With the latter I think that the best way forward would be to get your data sent in to the Data Repair team for analysis. Best bet would be to raise a support ticket with Developer Support through the usual channels and they should be able to sort out a secure upload of your data and raise the support ticket.
|
|
Rank: Member
Joined: 5/31/2012
Posts: 13
|
Sorry I can't copy & paste the version: the version is 18.0.10.208
Checked the permissions once again. The rest of the described issues seem fine.
SData is easy when it comes to development but I don't think we can use it for production due to these 'subtle' issues.
Unfortunately we will have to get back to COM (SDO).
Thanks for your help,
Reuben
|
|
|
Guest |
