I am dual-posting this here while I wait for DocuSign support to get around to assisting in the hopes someone here has some more insight.
Our application uses the DocuSignConnect API to manage brands. It has been in production for years and worked without issues. Sometime last week, our API calls to create brands began failing, but only on the Demo system. This functionality is continuing to work fine in the Production system. There are no code differences between our Demo and Prod environments.
In the past, we have seen issues (of a different kind) when changes are rolled out to the DocuSign Demo system. I wonder if this could be one of those scenarios.
The details are limited. Our API calls to create a brand are met with a failure with the following properties:
ErrorCode: 309
ErrorReason: Brands could not be created.
faultString: Brands could not be created. Unable to upload brand, error: Must specify valid information for parsing in the string.
As I mentioned above, our application has not changed recently with respect to the DocuSignConnect API. I have noticed, however, that the Signing and Email resource xml files appear to be undergoing a change (they differ significantly between DocuSign's Prod and Demo sites.) Perhaps this is a clue behind the fairly unhelpful "...specify valid information for parsing..." message.
My concern is that something is soon to be deployed to Production that will break our application.
I should add that our other API calls seem to be ok (sending envelopes, for example)
Has anyone experienced this type of problem creating brands?
The update on this from DocuSign support is that the 'type' attribute on the 'logo' element that is part of the XML schema defined in the 'CreateBrand' API call has changed from optional (in their PROD environment) to required (in their DEMO environment).
They are probably going to be changing their DEMO code to revert this attribute back to 'optional' before it is deployed to their PROD system.
But in any event, our code is going to change to start including the 'type' attribute on the 'logo' elements to ensure success going forward regardless.
Related
I work in a company where we have many different applications. To reduce code repetition and keep the experience for the users the same across applications we created a component library which is used by all applications.
Now we want to allow the users to switch between applications. Something similar like Google does:
Screenshot of Google Application Drawer
An additional requirement for our "Application Switcher" would be that it "updates" itself. Meaning if we change how this "Application Switcher" looks we don't want all applications which use this Switcher to create a new deployment and be newly deployed.
So currently we use the same header (from our component library) in all our applications. So, my idea was just to simply add a script tag to all the index.html pages of all the applications which should support this "Application Switcher". The Script would parse the DOM, find the header and inject a component for this application switcher. I wanted to host the actual script from a CDN like server and the script tag in the index.html just references this URL. This way we could change this script however we want, and all the applications will always get the latest version.
Now I did a small proof of concept in our environments and solved all the CORS issues but since we were fetching from an authenticated context and the script was also in an authenticated context I always got a 401.
Additionally, we have the requirement, that this "Application Switcher" shows different applications to different users i.e. depending on which apps a user is allowed to access. So, the script itself will also do calls to an "Application Switcher" backend providing it user-specific information.
Now this makes me think that my initial idea of just putting a script tag and fetching from a CDN was too simplistic. Now I'm thinking if it would be better to implement a rest endpoint in all applications to fetch this script. This way I don't have the problems of fetching a resource from an authenticated context from the user's browser and instead can handle all of this in the backend.
So long story short; I feel like a complete noob who just hacks around to get things working (or actually not working) and was wondering if any of the smart internet people out there (who might actually already have experience with this) could give me a hint what would be a clean way to implement this?
We are getting the errors while working with the client/contracts when managing it with API’s
Here is the scenario that we are facing:
We have an Api that we have created and added a contract to it:
Upon checking of API Contract, we are getting the following error:
Contract API Error
But the same with given endpoint is working fine while working it with key/client app using programmatically in our application, But when we are checking it with client's menu,
White Page Error
we are having totally blank white page ahead
Bug reports relating to Apiman should be filed in the "issues" section on the GitHub Apiman repository: https://github.com/apiman/apiman
The 'discussions' section is also available for more general help questions and topics if you are struggling with your configuration or migration (i.e. not really within Stack Overflow's area).
(Disclosure: I am Apiman's principal maintainer).
So this has been such an annoying issue I've been having with facebook.
We :
created a messenger app
verified the web-hook
submitted the app for review
got approval from Facebook
Everything works perfectly if we use the developers and users associated with the app, but for some reason any other user will not work at all!
The only explanation I see why it isn't work is because the app is in development mode, but apparently facebook removed that and replaced it with Access Levels.
I've been looking at documentation and can't find anything! Any directional help that I may have missed would be greatly appreciated!
The only explanation I see why it isn't work is because the app is in development mode, but apparently facebook removed that and replaced it with Access Levels.
You are indeed completely right!
The old system, consisting of Development Mode and Live Mode, has been replaced by respectively Standard Access and Advanced Access (cf. this documentation).
Apps in Development Mode can only request Permissions from app users who have a Role on the app or in a Business that has claimed the app. This is the same as Standard Access. Apps in Live Mode can request Permissions from anyone, but only if the Permissions have been approved through App Review. This is the same as Advanced Access. Features, although they cannot be requested from app users but are instead active/inactive, behave the same way.
This snippet was taken from this post.; Side note: They even wrote a paragraph about why they decided to switch and which features/improvements the new update brings - it's on the same site, just below the quote above
Anyhow, due to logistic reasons (supposedly) the update is only being pushed gently into the broad mass:
Access Levels are gradually being applied to all existing Business apps automatically.
You can find the banner on the previously mentioned site:
Summing up: Yes - the modes are actually replaced by their new "level system", though the update might haven't covered your Business app yet (but will so in the near future).
I got this message from API, maybe this covers the reason:
"(#10) Cannot message users who are not admins, developers or testers
of the app until pages_messaging permission is reviewed and the app is
live.", "type":"OAuthException", "code":10, "error_subcode":2018028, "fbtrace_id":"AL....i9"}}
Registering the same device with the same tags and template results in multiple identical registrations in the hub.
Will this cause a problem and will Azure eventually remove them?
It doesn't seem to result in duplicate messages sent to a device.
I figure I can limit duplicate registrations by checking to see if they exist first using GetRegistrationsByTagAsync.
Even that method only takes one tag, so it's then typically necessary to iterate over all the tags for each registration to complete a match. Plus, the device token needs to be added as a tag because the registration base class doesn't have a "token" property. (EDIT: Actually, that doesn't work because it says the token is an invalid tag. So I'm going for one installation per platform - perhaps I could switch on the installation's class type to get the token value.)
Honestly, this API seems somewhat half baked. Even the newer installation based part of the API doesn't even let you download all the installations so you have to have some way of keeping track of them if you want to update them. If you have to keep a copy of this data then you may as well skip Azure altogether.
You can get the installations from the Azure tab in Visual Studio but once deleted, it doesn't seem possible to reinstall a device.
What a mess.
I have a project where it was capturing custom events, exception, page views..
It is not throwing any error and working perfectly in my local machine and it was showing in the azure dashboard., The azure team has created the new dashboard and now i am seeing pageviews, exceptions but not custom events.,
I enabled the custom events option from the dashboard too... Even though it is not being displayed... If you see the exception it is custom exception and it thrown from the same code.. it works fine but custom event not...
Any idea....
Given that you've stated you are seeing pageviews and exceptions, and that you have a class i'm presuming 2 things about your project:
asp.net, using the .net ApplicationInsights.Web, etc nuget packages
web pages, using the Javascript application insights snippet+etc.
Given those 2 assumptions, i'm presuming your custom events are in the c# code?
If you're seeing pageviews and browser exceptions, that means the instrumentation key being used by the javascript code is one thing, (probably hardcoded directly in _layout.cshtml or something similar?) and the instrumentation key used by the asp.net code is something else, (probably coming from applicationinsights.config file?)
If you've changed the instrumentation key in one place, make sure you've changed it in both.
One way to verify this is to use something like Fiddler, and go to your site, and watch for calls to dc.services.visualstudio.com (those are calls from the sdks to send data). the javascript code will make some calls, and the asp.net code will make its own calls. inside the outbound data will be instrumentation keys, and you can se which one is using which, and which one you need to fix.