How to set Mandatory flag on RabbitMQ message - c#

The RabbitMQ documentation make reference to a mandatory flag that can be set on a message that will cause the broker to respond with a BasicReturn instead of a BasicAck if a message cannot be routed to an Exchange.
However, I cannot find any example of how to actually set that flag when publishing a message. How would I go about setting that on a message?

If I had to discover this answer myself, I would first start by searching the code for the library using the keyword mandatory:
https://github.com/rabbitmq/rabbitmq-dotnet-client/search?q=mandatory
That leads to the correct answer pretty quickly:
Use the mandatory boolean argument to BasicPublish
Other potential searches and resource links:
Google Search
RabbitMQ .NET API Reference Docs
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.

Related

Label not available in Azure.Messaging.ServiceBus.ServiceBus.ServiceBusMessage

I am migrating to Azure.Messaging.ServiceBus and have noticed that there is now no longer a property called Label
This is a huge problem as Label is used in our service bus rules to filter messages on a subscription.
What is the equivalant of setting message using the Azure.Messaging.ServiceBus and ServiceBusMessage
If I have to use Subject thats really bad because I would have to change every single rule in our service bus which is a total nightmare
Cheers
Paul
What is the equivalant of setting message using the Azure.Messaging.ServiceBus and ServiceBusMessage
That'd be the Subject property.
If I have to use Subject thats really bad because I would have to change every single rule in our service bus which is a total nightmare
You don't need to change anything on the broker side. The SDK (Azure.Messaging.ServiceBus) is a client-side SDK. Subject will be converted to Label and you don't need to modify the existing subscriptions rules. See documentation here.

How to modify in C # the time that Kafka keeps the messages of a topic?

I am looking for documentation about it and I see that there is a property called retention to determine the time that the messages of a topic are kept in Kafka. The problem is that I cannot find that property or any similar property to apply in C # code.
Anyone who can help me with this?
There will be no C# property because these are strings in all clients except for the Java clients where there's enum values for client and topic configs
In the AdminClient you can create topics with a second optional parameter that accepts an object containing the values you're interested in
https://github.com/confluentinc/confluent-kafka-dotnet/issues/861
How to create a Kafka Topic using Confluent.Kafka .Net Client

Concerning Paypal and classic API

I have few questions concerning PayPal and Classic API. I have spent the last few days reading and experimenting with 1. Single PayPal Payment using variables and HTML post form. 2. Idem but for recurring/subscription payments. Even though I almost succeed to do most of what I want to accomplish, I still have few questions and grey zone I'd like to debunk.
Here it is:
Is it possible to use classic API, HTML form, PayPal variables and post a request to PayPal/Sandbox AND ONLY use credit card information, without having to log in PayPal or have a PayPal account? I never succeed and PayPal always block after you hit the PAY button, returning security codes error message or wrong card/account number etc.
If yes, how and where can I find a real code sample or demo for HTML/MVC-C#?
After a make a payment, I receive an invalid response which nothing happens, then, I receive a second IPN response and this one is verified etc. DO I really need to reply to PayPal/Sandbox to tell them everything is OK? If yes, is there info somewhere or code sample/demo I can see? MY point here is because i receive MANY hits on my IPN and I want to make sure I get the right response, make sure i don't DOUBLE subscribe etc..
Is there A GOOD MVC or C# IPN code sample somewhere? One I could read and analyse/take to handle most possible scenarios/errors/response code and what to do with them? not to copy and paste but something reliable I could adapt to my code.
I have succeeded to get a response to my IPN with a PayPal account only and I had to somehow hack security protocol using this instruction --> ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;//SecurityProtocolType.Tls1.2; and I also had to use ngrok to provide a 'valid' return URL. My question here is, Do I Need to remove that instruction when I go PROD?
Thank you so much in advance,
Mart.
Yes, but this is one of the reasons the question got voted down. You need to sign up for Payments Pro to do credit cards (or you could also use the REST API) and then you would use those specific APIs to process credit cards. The thing is, depending on what version of Pro you end up with or if you decide to go with REST, the APIs are different, so it's hard for anybody to tell you what to use at this point.
Yes, you need to POST back to PayPal to verify that the data actually came from them. This way you can trash any data where wannabe hackers are posting garbage to your IPN listener or anything else like that going on.
As long as your IPN script completes with a successful 200 response back from your server then PayPal will only send a single IPN. If you're getting multiples you must have a failure going on, in which case you'll need to troubleshoot that accordingly.
Yes, PayPal provides lots of sample code. This is another reason your question may have been voted down. It seems you have not taken the time to look into this stuff yourself. Go to http://developer.paypal.com and upon reviewing the APIs you'll find they provide SDKs for different languages. Each of those comes with samples, and their GitHub repos also include samples.
With a quick Google search you'll find loads of tutorials and samples as well, of course.
Within the developer site you'll also find the Integration Wizard, which will let you choose C#, choose the payment integration you want, and it will build it all for you so you can see how it works.
Then, when working on those samples or trying actual code, if you have specific problems / questions, you'd come here and post that specific issue with a code sample that you've tried. Then people here will be happy to help.
TLS 1.2 is a standard requirement for pretty much all web services now because of security vulnerabilities in SSLv3. If you have "hack" anything (outside of configuration files, maybe) then you're probably doing something unnecessary. All it would require is to ensure the software stack on your server not only supports TLS 1.2 HTTP requests, but also uses it by default.

Office 365 Rest API read the In-Reply-To field

I am using the rest API documented here https://msdn.microsoft.com/office/office365/APi/mail-rest-operations and https://visualstudiogallery.msdn.microsoft.com/a15b85e6-69a7-4fdf-adda-a38066bb5155 to analyze e-mails in an application. When I "View message details" in Outlook I see the header fields for:
Message-ID: <1421862991001.54993#domain.com>
References: <1421861073749.70076#domain.com>
In-Reply-To: <1421861073749.70076#domain.com>
Is there a way to access these fields through the rest api? The api returns a ConversationId and Id, but those have different values and nothing that can give the context of a message like In-Reply-To does. I realize since these fields aren't documented my answer will be no, but perhaps there is some other way?
I realize this isn't a great example of a programming related question, but I've read this is the best place to interact with the developers at MS responsible for these APIs.
You're right, there isn't a way currently. Accessing the headers (or even the full MIME) would definitely be useful, I will make sure it's passed along.
Chiming in here since it's been a few months since this question was answered.
Accessing the full header information via the REST api would be useful for a variety of reasons, including detecting auto-replies. It'd be great to see this feature happen!

Localization in a WCF server

I am fairly well versed in using localization in a simple WPF UI application.
I am now in the process of developing a WCF client/server architecture; I want to be able to create various types of exception in the server, and have the error message in the culture of the client.
This seems straightforward enough - somehow we will identify the culture being used by the particular WCF client at the time.
However, I want the messages to potentially also be logged into the server's logfile in one language (typically English) to allow easier support of the application.
There are various assemblies used in both the server and the client side; each assembly is going to have a string table of error messages. Therefore when an exception is created, it needs to have the resource ID and the resource manager for that given assembly to hand. Without sub-classing each available exception type, I cannot see how to get around this. This seems like a lot of work for a problem that has surely been encountered before?
Example
Server.A.dll
Error Resources: MyErrorString1, MyErrorString2
Resource Manager: ResourceManagerA
Server.B.dll
Error Resources: MyErrorString3
Resource Manager: ResourceManagerB
So ideally I need to have access to the resource manager for a given string at the time I need to either log the message to the file or send it back over WCF as a fault; but I don't want to lose the ability to catch types of exceptions by using one generic exception class.
Does anyone have any experience of this problem, or any cool suggestions on how to go about implementing it?
Thanks in advance,
Steve
I don't think that is good idea to show plain Exception messages to users. Instead, I would catch them log them and show friendly message in UI. That way you won't need to subclass anything...
If it is a technical exception, there is no need for details that the user won't understand anyway. Just display a generic error message.
As for expected error condition, they should be cataloged somewhere. Then you just need to exchange error codes between client and server and do the localization on the client based on the error code.

Categories