Just hooked SignalR.WindowsAzureServiceBus to my web project and it appears to cause a problem in the SignalR.Client library. I get the following error when I send a message:
Format Exception: Input string was not in a correct format.
So I downloaded the source and debugged and this is the offending line of code
connection.MessageId = result["MessageId"].Value<long>();
#SignalR.Client.Transports.HttpBasedTransport.ProcessResponse(...)
[SignalR.Client.Silverlight5]
It results from trying to parse the following JSON pair's value to a long:
"MessageId": "3wIAASMAAAA%3D"
It appears that with Service Bus enabled, the MessageId is not a long, as "3wIAASMAAAA%3D" is clearly not parsable to a long.
I see the topics are created in the Azure management portal, so I know it's connecting to the Service Bus just fine.
Did I do something silly or do I need to patch it for a workaround?
Seems like a bug. I've opened an issue on github. https://github.com/SignalR/SignalR/issues/475
Related
As the title says im trying to send '\n' seperated set based commands to juniper device using load_merge_candidate with napalm (driver is junos). But i see it throwing MergeException with this message 'napalm.base.exceptions.UnlockError: UnlockError(severity: error, bad_element: None, message: Configuration database is not open)'. But when passed individual/ single line commands one at a time as string i see it going through fine. I dont see this issue with ios-xr driver though. Im little surprised to see this issue with junos driver. Now im passing the big config through filename argument which doesnt seem to have issue. Can someone shed some light if im doing anything wrong with string/ config option? or is it a limitation?
I've verified my API in RStudio after hours of trying and now I've reached another error while trying to translate a sentence. Would be grateful for any help!
I'm just trying to translate "hello" to french using googleLanguageR package -
> gl_translate("Hello", "fr")
The result I get is this -
2021-01-21 17:15:36 -- Translating text: 5 characters -
i 2021-01-21 17:15:36 > Request Status Code: 403
Error: API returned: Request had insufficient authentication scopes.
I'm a literal beginner in the field of computing and do not understand what scopes mean here.
Thanks for the help!
Scopes are permissions that you give to apps you use to access an API. For example, one App might have permission to read the private messages of a users, whereas another doesn't. It's similar to when an app on your phone asks for permission to use the camera, or access your contacts.
Your app is trying to do something that it doesn't have permission to do. You'll need to add the relevant scopes in whatever setting that it is where you're generating keys etc. Presumably Google Data Studio?
Okay, I found an answer.
I needed to download a json version of my key and authorize it using the code -
gl_auth("filename.json")
After doing this, I needed to make sure my API is enabled. Now, it is working perfectly!
Cross-posting with this on the IBM forums: https://www.ibm.com/mysupport/s/forumsquestion?id=0D50z00006egDnsCAE. Follow-up question located here: Having trouble connecting to iSeries from .NET Core
Hi all,
I'm very new to this whole thing, so let me know if there's any info which would help, that I'm not providing.
At the moment I'm just trying to get the very basics working - getting the connection to open. I have a stripped-down .NET Core project, which is simply exposing a button I can press that opens a connection for DB2. My code is as follows:
using IBM.Data.DB2.Core;
...
DB2Connection DB2Connection = new DB2Connection(connectionString);
DB2Connection.SystemNaming = true;
DB2Connection.Open();
My connection string is as follows:
"Server=###.###.###.###;Database=AAAA;UID=BBBB;PWD=CCCC;LibraryList=DDDD,EEEE;"
I'm getting the following exception:
IBM.Data.DB2.Core.DB2Exception (0x80004005): ERROR [08001] [IBM] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: "###.###.###.###". Communication function detecting the error: "connect". Protocol specific error code(s): "10061", "*", "*". SQLSTATE=08001
I really don't know how to proceed from here. For context - I'm using "IBM Navigator for i" to query the info directly, and that works just fine for the IP, User ID, and Password I used above.
I've done some reading up, and attempted a few different solutions, but none really helped. I did see that in "Integrating DB2 Universal Universal Database for iSeries with for iSeries with Microsoft ADO .NET", it suggested looking in the Work Management section of the navigator, and check under Server Jobs to see whether there was any added info - however, it does not appear there is anything there to see.
I do understand that I may require a license for this connection to work properly, and accept that if that ends up being the problem, I'll need to get the license - but I don't think I've reached that stage yet. For now I just want to make sure the connection itself works properly.
Any help or insights are greatly appreciated. Thank you.
The symptom SQL30081N with 10061 was resolved by including the PORT=xxx; in the connection string, where xxx is the correct TCP/IP port number on which the Db2-for-i-series is listening for connections.
Let's see if you experts have a clue of what's going on here.
Context
We have a web application running on Azure Web Sites. This WebApp uses OWIN + OpenID Connect to authenticate users against an Azure Active Directory tenant. Also the application uses the Azure AD Graph API to collect some data of the directory.
We based our code on this sample project provided in GitHub: https://github.com/AzureADSamples/WebApp-GraphAPI-DotNet
Issue
The WebApp was working perfectly some hours ago (authenticating to the AD and fetching data from the directory), but then the weirdest thing happened to us. Today we found that we could still authenticate against the AD but the Graph API was throwing errors almost randomly.
We traced the error down to a specific request, when trying to get a specific user by ObjectId in a synchronous way:
Claim claimObject = ClaimsPrincipal.Current.FindFirst(Helper.Constants.ADTenant.ObjectIdClaimType);
string userObjectID = claimObject == null ? string.Empty : claimObject.Value;
ActiveDirectoryClient client = AuthenticationHelper.GetActiveDirectoryClient();
List<IUser> users = client.Users.Where(u => u.ObjectId == userObjectID).ExecuteAsync()
.Result.CurrentPage.ToList();
The thing is the last line throws an exception regarding the OData model:
"A value without a type name was found and no expected type is available. When the model is specified, each value in the payload must have a type which can be either specified in the payload, explicitly by the caller or implicitly inferred from the parent value."
We started slicing the last line of code into pieces as follows:
IReadOnlyQueryableSet<IUser> queryUsers = client.Users.Where(u => u.ObjectId == userObjectID);
IPagedCollection<IUser> pagedUserCollection = queryUsers.ExecuteAsync().Result;
List<IUser> users = pagedUserCollection.CurrentPage.ToList();
And found the exception was throwing in this line:
IPagedCollection<IUser> pagedUserCollection = queryUsers.ExecuteAsync().Result;
Weirdest thing is that this line was executing fine yesterday and today started failing without explanation.
Does anyone know what are we doing wrong? Why did it start failing today?
Remarks
We are using api-version=2013-11-8. We kept the Azure AD Graph API Client Library on version 1.0, as in the sample on GitHub.
Folks,
First of all - many apologies for introducing this problem. The underlying problem is that an entity (User entity in this case) was updated on the service side, with a new collection (AlternativeSignInNamesInfo). Typically adding new entities, properties, collections and complex types should not cause a breaking change for the client library. However due to an issue in ODatalib, unknown collections are not simply ignored.
I totally agree with the sentiment on this, and we absolutely do NOT want to have apps that take a dependency on the Graph Client Library be subject to ANY outages. We are working with the ODatalib team to get this issue rectified, so that this is no longer a problem with our Graph client library moving forward.
In the meantime we are in the process of rolling back our Graph service, so that 2.0.5 should start to work again. Version 2.0.6 should also work - as long as you don't try and post to the new collection on the User object (AlternativeSignInNamesInfo).
UPDATE: The Graph service has been rolled back. I’ve also verified that getting a user through Graph Client Library 2.0.5 AND 2.0.6 both work.
Hope this helps and again sorry for any issues caused here.
I had the same problem just now! I have an application which have been working for a couple of weeks and hasn't been changed. I've got it working by upgrading "Microsoft.Azure.ActiveDirectory.GraphClient" from version 2.0.5 to 2.0.6
Yes upgrading the graph client Nuget package to the latest 2.0.6 fixed this problem. I had a similar panic this morning too. It's an unbelievable fact that Microsoft rolled out a new version of the dll which breaks applications run on previous version!
My team had similar experience. After installing 2.06 our code started working again. Took the entire day with first discovering, fixing, and then testing the solution.
I have a StoredProcedure that returns a simple table containing several records:
DECLARE #STEPS_TABLE AS TABLE (OrchestrationID uniqueidentifier, [Message] nvarchar(1000));
-- LOADING THE VALUES HERE
SELECT * FROM #STEPS_TABLE As Step FOR XML AUTO, XMLDATA, ELEMENTS
I used the SQL Transport Schema Generation Wizard to create my schema and could configure the port correctly. If I use this schema on my orchestration, it works perfectly. BizTalk starts one instance of the orchestration everytime the #STEPS_TABLE has more than 1 record.
Reading Microsoft technical documentation, they recommend to get several messages in one call and then use the XML pipeline to disassemble the multi-row BizTalk message into a single-row BizTalk message.
I haven't used the XML pipeline before, so I tried the provided steps but couldn't get it to work.
Could somebody provide me a link to a "how to" (didn't find anything until now, after several hours of searching) or give me some hints to succeed.
Thanks in advance.
... some hours later I could figure it out myself. So if anybody comes across the same issue as me, here you have some guidelines to make it work on your environment.
At the end I followed a different walkthrough from Microsoft and avoided the pipeline recommendation altogether. The documentation I found is called "Disassembling Result Sets Using the SQL Adapter" and does exactly what i was looking for. You can just follow the whole walkthrough from Microsoft but avoid the creation of the send port and make some little adjustment on the receive port.
After following the technical document you will end up with two schemas, I will call them message and envelope (contains several messages) for the sake of this excercise. In your orchestration you can create a receiving port that maps to the message and then when you configure it as a SQL Port and you link it to your stored procedure (or select statement), you only have to change the Document Root Element Name to the envelope root name; the XML Receive pipeline (provided by default in BizTalk 2006) will do the magic of disassembling the messages contained in the envelope and instantiating an orchestration for each message.
The Microsoft "Disassembling Result Sets Using the SQL Adapter" walkthrough can be found under:
http://msdn.microsoft.com/en-us/library/aa562098(v=bts.20).aspx
Mission accomplished :)