According to the rest api documentation it is recommended to assign a payer_id when saving a card to the vault.
My problem is that there is no payer_id property to populate for the creditCard object in the first place.
creditCard.number = "4417119669820331";
creditCard.expire_month = "11";
creditCard.expire_year = "2018";
creditCard.first_name = "Joe";
creditCard.last_name = "Shopper";
creditCard.type = "visa";
**creditCard.payer_id = "123456789";**
As far as I am aware I am using the latest APIs updated by Nuget in VS2012.
Here's the response from the PayPal Vault API team:
The payer_id field was never removed. We've intended to deprecate/discourage its use because we determined that this field was misleading in the way it was named - it was being mistaken for a PayPal's internal identifier, where in reality, to PayPal, it was just an arbitrary string, intending to identify an externally managed customer id. The Vault team has since added a field named external_customer_id that better captures the intent.
The external_customer_id property (found here in the current version of the SDK) is what should be used instead. However, since the payer_id property will continue to be supported in the v1 version of the Vault REST services, the .NET SDK will continue to provide support for this (the upcoming v1.1 .NET SDK release will include it again).
The PayPal documentation team is working on getting the public documentation for the credit card object updated to include this information.
For future reference by other developers who may find this post, I'd like to add that if you do find a property missing from the PayPal .NET SDK, a better place to report this is to open an issue on the PayPal .NET SDK GitHub repository where the code for the SDK resides.
Related
I've currently got a Bot running in Microsoft Teams, which has been built many years ago using the Microsoft Bot Framework v3 SDK. Now I will show an example of a location where I have saved some data after using the Bot, which I understand is stored in the "IBotDataBag".
So this method is the first method that is called when I enter a message to the Bot in Teams (as a result of the framework). It is injected with an object of type "IDialogContext" and this object contains other objects, one, which is of type "IBotData" and above in the image is "context.UserData". I use this to set some data, for example I had set it to store a value inside the key of "test_data", which I retrieve in the image above.
Now my question is, where in the Bot application is this data actually held? My application is deployed to Azure as an application service. It is installed locally in my Microsoft Teams after installing it from my Org's application catalogue. I want to know whether this data is held somewhere locally on my PC or in the cloud somewhere. Based on a test by uninstalling the Bot I thought if it was held in the cloud then the data set in the "IBotDataBag" would be removed but after installing the Bot after, the information was still present, which leads me to believe the Bot held onto the information locally on my machine. I have tried to find information to support this conclusion online but I have not spotted anything useful so far and I understand Microsoft are now very much pushing SDK v4 so was hoping someone on here can shed some light on the question for me please?
So after reviewing the architecture of the bot in its resource group in the Microsoft Azure portal, I found an entry of type "Storage Account", which is basically Azure Table Storage for the bot. In here there is a section for "Tables" and in here you will find an entry called "botdata". Inside of this table you will find several entries, which are identifiable by their partition key. After running doing some trial and error I found that removing the "msteams:user" entries would result in my bot not having any "UserData" inside of the context object. Based on several tests, I concluded that the data is held in table storage and that the bot framework handles the CRUD operations on this data.
The V3 SDK is being retired with final long-term support ending on December 31st, 2019. Accordingly, there will be no more development in this repo.We highly recommend that you start migrating your V3 bots to V4.
The v3 SDK currently supports two programing language. Bot builder SDK v3 includes samples for all supported languages:
.NET
JavaScript
Here some Code snippest-
private async Task MessageReceivedAsync(IDialogContext context,
IAwaitable result)
{
var activity = await result as Activity;
// An example of a string value saved directly to UserData
context.UserData.SetValue("test", "test");
// If we have not asked the user their name, ask it now
var askedName = context.UserData.GetValueOrDefault<bool>(AskedNameProperty);
if (!askedName)
{
await context.PostAsync($"v3: Hi. What is your name?");
// We've asked the user their name, so persist the information in UserData
context.UserData.SetValue(AskedNameProperty, true);
}
Reference Sample-https://github.com/microsoft/BotBuilder-Samples/blob/4d209edeaaaa72d29279057ff2c1ac3ce213694b/Migration/MigrationV3V4/CSharp/V3StateBot/V3StateBot/Dialogs/RootDialog.cs
Document-https://github.com/microsoft/botbuilder-v3
I have a service that manages all of the indexes/indxers I use for Azure Cognitive Search, and within that I am attempting to set disableOrderByHighWaterMarkColumn to true when creating/updating an indexer.
While I do see examples in the official docs for an HTTP request to set that field, I'm not seeing any parameter anywhere (including the Parameters option under the SearchIndexer object) that can be set to update that value.
Does nadisableOrderByHighWaterMarkColumn` through the C# API? I have the latest Azure.Search.Documents package installed.
You would need to add it as a custom key under the SearchIndexer.Parameters.IndexingParametersConfiguration property.
If for some reason that doesn't work as expected, then it is a bug with the .NET SDK that I would suggest you submit as an issue against the official Github repository.
I tried to get the content of the user's profile picture and I found out that I had to call the Beta version because the current version gives the following error message:
"code": "GetUserPhoto",
"message": "The operation is not supported."
So, I tried to switch to Beta, and here is the code that I wrote in C# to do it, but it doesn't work:
Microsoft.Graph 1.6.2
List<QueryOption> options = new List<QueryOption>
{
new QueryOption("$api-version", "beta")
};
var pictureStream = await graphClient.Me.Photo.Content.Request(options).GetAsync();
I got the same error message.
I tried the same request in the Graph Explorer. The 1.0 doesn't work, but Beta works.
The api-version query parameter is used by the Azure AD Graph API. This is a different API than Microsoft Graph. There is a lot of functional overlap (Azure AD Graph is slowly being migrated over to Microsoft Graph) but they use entirely different entities and calling conventions.
In order to call the /beta endpoint using the Microsoft Graph .NET Client Library, you need to change the BaseUrl of the client:
graphClient.BaseUrl = "https://graph.microsoft.com/beta";
var pictureStream = await graphClient.Me.Photo.Content.Request().GetAsync();
Some important notes about the /beta endpoint:
It isn't supported and isn't suitable for production. So don't do that. Or at least don't tell anyone and don't call Support if it stops working. ;-)
The .NET Client uses objects constructed off the production metadata. This means that any entities, actions or properties that were added in /beta don't exist in the models shipped with the SDK.
The .NET Client will ignore any values returned by Microsoft Graph that it doesn't expect to see. So if an endpoint returns a property that wasn't included in the production metadata (see #2), it will simply be ignored.
So long as you're only using a /beta to gain functionality but still expecting /v1.0 results, it should work okay. Photos for example only look at Exchange in v1.0 but look in both Exchange and Active Directory but still return the same result. In theory this means you should be able to swap /beta for /v1.0 without a problem.
I think you are still calling V1 endpoint. In fact, the Beta endpoint is not currently supported in the Microsoft Graph .NET Client Library. More info here.
There is an official beta client for Graph API now:
https://github.com/microsoftgraph/msgraph-beta-sdk-dotnet
Trying to use custom application configuration in my service. This post gives part of the answer, but it doesn't explain how & where you initialize the ServiceInitializationParameters object, which is required to get it working. The object does not seem to have a constructor. Documentation from Microsoft is sketchy and the provided sample on GitHub does not seem to use any custom app config.
This post is based on the preview SDK. In the release version (2.0+) of the SDK, ServiceInitializationParameters was replaced with ServiceContext and its derived stateless and stateful versions. Check out the release notes for a comprehensive list of all the changes from preview to release.
Everything else in this post is still accurate, but you access the config stuff like this now:
var configurationPackage = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");
var connectionStringParameter = configurationPackage.Settings.Sections["UserDatabase"].Parameters["UserDatabaseConnectionString"];
The documentation for the PayPal Rest API SDK for .NET indicates the payer_info.shipping_address is deprecated / obsolete.
https://github.com/paypal/PayPal-NET-SDK/blob/develop/Source/SDK/Api/PayerInfo.cs
Obsolete. Use shipping address present in purchase unit.
What would be the correct field to use to retrieve the payer's shipping address then, using the Get method? I don't see any field called purchase unit or the like returned in the Get method.
I should note, it seems the shipping_address is populated correctly still.
I just got a response from PayPal MTS and clarified the documentation is from an older version and is wrong.
https://github.com/paypal/PayPal-NET-SDK/issues/123