I am receiving a weird error when my SOA system is trying to call a decision service.
Has anybody seen an error like this before and knows how to get around it?
There are multiple decision services within my application and I read online that this can be a bug within SOA, however, this was working before and then suddenly start giving this error.
If more specific detail is required then please let me know and I can provide it
but for now, I am purposely leaving this question without specific details in order to target those who may have encountered this error before.
Thanks!
The answer to this issue was to reload the facts inside my decision service.
Related
Seems like every other day XrmToolBox's Plugin Registration tool fails to connect. It's probably the most fickle tool I've ever used professionally (is this really the best tool for the job? yikes)
In years of working with it, I've not yet found a reliable way to get the tool to connect. Everything connects fine in the browser. But XrmToolBox randomly fails.
And I've never found or read online a reliable way to figure it out except restart your computer, throw salt over your shoulder, spin counter-clockwise once in your chair, try again later.
Anyone have a better way?
The server was unable to process the request due to an internal error.
For more information about the error, either turn on
IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute
or from the configuration behavior) on the server in
order to send the exception information back to the client, or turn on
tracing as per the Microsoft .NET Framework SDK documentation and
inspect the server trace logs.
That was the only error I got from XrmToolBox. But it led me to solving the problem. Followed this article to enable more detailed error log:
https://community.adxstudio.com/products/adxstudio-portals/documentation/developers-guide/knowledge-base/enable-detailed-errors-on-the-organization-service/
Tried again, and saw that indeed there was a meaningful error in the XrmToolBox logs.
TL;DR: Turn on better error logging in the on-premise CRM web.config! Then try again to get a more helpful error.
We create classes for multiple school districts via googles classroom api. We noticed that on 2017-12-18 we had multiple classes have their Aliases removed (We ended up creating duplicate classes as we use this alias for our unique ID). We use a domain-scoped alias as defined here https://developers.google.com/classroom/reference/rest/v1/courses.aliases
Any ideas? I'll keep this updated as we find more information.
Google found the root cause on their end. This was a google issue.
Note: I did remove some of the messages from google but nothing context related just some specific things about questions related to our company.
Hello *****,
I hope this message finds you well. This is a follow up message
concerning your case with Google Cloud Support.
I would like to inform you that we just received an update from our
Engineering Team regarding the bug that was affecting the Classroom
Aliases. According to the update received, our Engineering Team was
able to identify the root cause of the issue and the issue is now
fully resolved. This means that the aliases will no longer clear when
making update to the courses via API. I possible, we would like to
know if you are still seeing aliases that are deleted or seemingly
disappearing?
According to the information and due to the nature of this bug, our
Engineering Team will not be able to restore the previously deleted
aliases but they are working on creating an alternative solution in
case anyone else encounters this issue in the future. This means that
they will have a way to recover aliases in the future in case they are
deleted by a bug or issue in our end. Please rest assured that this
API issue should not occur again but if it does, we will have a way to
get those aliases restored.
I suggest that you recreate the aliases, test to see if there is any
other issues and let me know if you need any additional help or if you
have any questions regarding the above response. Again, we really
appreciate your patience and continued support while we work to
identify the root cause of this issue.
The best way to reach or API Team is by opening a support case and
wait for us to reply back via email or wait for a call back. We will
normally sent an email requesting the best time and phone number to
contact you back. You can also reply to any of our cases during a
period of 30 days and your will be be reopened and I will be able to
contact you back as soon as possible.
Sincerely,
Google Cloud Support
TL;DR: Basically what I am looking for is a way to get a list of all sonar rules that have 0 issues raised. I could then move all of those to blockers and protect myself from someone adding that issue in the future.
My company is using sonar and static analysis to help guide refactoring and development of a sizable legacy codebase (~750K LOC). We have had a lot of success by lowering the severity of most rules and then choosing a smaller set of rules to promote up to blocker or critical as we find real issues in the code. This has kept the number of issues we are trying to address at a time manageable so we can actually feel like we are making progress and not drown in the noise of legacy issues.
In particular when we have been bitten by a field or QA issue that sonar could have detected we turn that issue up to a BLOCKER and fix every instance of in. These blockers break the build and we are now assured that we wont add a new instance of the same issue again. This has worked great and has kept a number of what would be nasty bugs from slipping through.
The big problem with that methodology is we need to have an example of every one of those classes of mistake atleast once in the codebase so we could learn that it was important and should be made a blocker. Any issues we haven't already encountered will still be at their default level, I'd like to move all of them up to BLOCKER now so we notice the day they are added.
Edit: Currently we are using 3.7.3 but we are about to upgrade to 5.X.
There are 2 ways to do this:
1- The difficult way is to query the SonarQube database. You have to understand the tables and write a SQL query based on which DB is used for your SonarQube. You Can find some reference here - OR here
2- I have never tried your method but it should work. You can use Sonar Web Service API. You also have a Web Service Java Client. Reference :
link1,link2,link3
First off, The Problem:
We have a Web App with a Flash front-end that talks to our ASP.NET web service via SOAP which then deals with all of our server side code (C#).
Right now, we implement a simple user sign on in our application, storing the info in our MSSQL DB.
A client has requested what I understand to be Windows authentication through our application using the currently logged in user.
So, I have been tasked with investigating this. Nobody, including myself, has any experience in this area.
I have been reading up on some basic Active Directory information, and some simple tutorials. I understand how to get access to the directory using ADSI through code. What I'm really interested in seeing is how the entire thing should be architected. I don't want to throw together a hacky solution.
Does anyone know of a good tutorial for this kind of thing or have any advice on getting started? More importantly, does this even sound viable?
I know I haven't given much information, but feel free to ask and I will provide answers.
Thanks.
Edit:
Will, to give you an idea of the scope of this, the network will include every computer in a large hospital. So yes, this is huge. Clearly I need to start small. I would like to come up with something that will work at my office first. Maybe ~10 Windows computers on a single domain. One Domain Controller.
I am also open to any good books on the subject.
If you are going to tie into Active Directory you will want to take a look at the System.DirectoryServices namespace. The implementations can vary wildly depending on your system architecture, but this should give you a good starting point.
Enjoy!
A common problem I find when dealing with non-technical users when supporting technical issues is "translating" what I'm hearing to what actually is causing the problem. In our current application we do things like provide error message details that can be forwarded to our support team, however my question is:
1. Is there an approach that any of you have implemented and found successful in helping the user provide quality information about application issues that can help in troubleshooting? If so what is that approach?
What I'm hoping for is a clever approach to designing error message displays in such a way that when the user communicates the issue, it is a better primer for quickly resolving the issue. Thanks!
I've found that logging of end user activities and errors is an effective tool as this reduces the amount of information you require from the end user.
You can also ask the end user to provide screenshots which typically captures URLs, input, error messages, etc..
EDIT: In my experience though, any prompt for information even when provided to help desk staff is typically ignored or misinterpreted. My suggestion is to capture as much information as you can automatically as that eliminates human error/oversight.
If your users aren't computer litterate, then you should use VNC to see what's happening on their computers. Despite network lag, you should be able to see more things happen than the user does
When your application encounters an error, have it log or "phone home" the actual error in addition to showing an error message to the user. The user can then send you the error logs (or you can look at them in your error database if the application "phones home"). This way you can get more detailed information directly from the application. Logging additional information about the application state will help to isolate what the user is doing when the error occurs. You may want to include the ability to turn this logging on/off so that it only occurs, or occurs at different levels, based on some flag. This would allow you to restrict some logging to only those situation that require extensive logging to narrow down the problem.