My company uses a systemd service that makes rest api calls to the podio API in a python wrapper on a services server. The process takes in bugsnag bugs, checks that a podio bug item with that external ID already exists, and then creates a new podio bug if no associated podio bug exists and updates any existing item if one does exist. Recently, this check was behaving unpredicatably. It would encounter a request for a given bugsnag ID and for no discernable reason would fail to find a podio bug with a matching external ID on one call, and then successfully find one the next call. The specific API rest call is https://developers.podio.com/doc/items/filter-items-4496747, filtering by external ID.
We haven't been able to recreate the issue on local testing, and reverting the code running on our services server to before a major refactor (the issue started happening around the same time) didn't stop the issue from happening. Was there a change in how the filter request works recently? Even so, that wouldn't explain why we are getting different responses for the same call.
don't know if I'm handing you a Red Herring but, I had to rewrite my Podio.Net code because all the references to integer Podio ItemIds were acting erratically like you described. The issue was that Podio's Id numbering system exceeded the size of an Integer and I had to switch all the calls to Long ItemId values.
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
We are trying to build custom stock levels based on the Warehouse, a user selected. Until the user does not have a selected Warehouse, the stock level should be 0.
Now we are experiencing weird behaviour, where it still shows a Stock Level of 0, even though the user has selected a store with valid stock level for that product.
After some researching, we found several places in the java code, where calls like e.g. getProduct are being cached for 120 seconds or more. I guess this is done due to performance improvements..?
This cache control and max age for these calls even seems to persist over fresh incognito windows in e.g. google chrome.. Sometimes the getProduct call is not even executed (Not listed in the network tab) and only get's executed after several hard refresh reloads (but still gives back the cached and therefore wrong response).
Sometimes it seems, that the cache persists for even longer than this 120 seconds, we haven't figured out yet, why..
This page explains how the caching can be implemented, but it does not say, how the server side caching works: https://help.sap.com/viewer/9d346683b0084da2938be8a285c0c27a/1905/en-US/8b711228866910149500b73575cb386e.html
My Questions around it:
How does the Server side caching work, how can it be invalidated (besides turning off the whole feature)
How should dynamic Product information be handled? Should the whole cache be disabled or rather a custom OCC endpoint be used to get the stock level?
In the mean time we partially figured out, how we guess it works:
Server side Caching is done via EHCache, the time to live is defined in ehcache.xml
we needed to enhance the cache for productCode to also contain the selected store
Besides "fixing" the server side caching, we still have the problem, the the data is getting cached in the browser (we assume via Etag header, which is based on the response body). As the response body does not know anything about the selected store (sent via http header), it doesn't change, and therefore the data is not requested again after selecting the store..
Any idea on how include the information from the http header into the Etag value?
I have a working QnA Maker instance, I manually added a few URLs to public websites.
Now I want to add many more URLs. I guess this means mastering the REST API? What method should I call? Any examples to start from?
I found this sample, which got me started:
https://learn.microsoft.com/en-us/azure/cognitive-services/QnAMaker/quickstarts/create-new-kb-python
It's an example of calling the REST API's "Knowledgebase - Create" operation.
https://learn.microsoft.com/en-us/rest/api/cognitiveservices/qnamaker/knowledgebase/create
It crashes if you add more than 10 URLs. Eventually, I found there are limits of 10 URLs on create.
Adding more requires a separate REST call - "Knowledgebase - Update" with an "add" node in the request body.
https://learn.microsoft.com/en-us/rest/api/cognitiveservices/qnamaker/knowledgebase/update
I think this is limited to 5 URLs per call. I extended the python code to loop over my list of URLs and "add" them all. It seems to work but gets slower and slower to complete each call. My guess is QnA Maker re-runs some internal indexing logic over the whole knowledge base on every update call? If so then that limit per call is probably counter-productive.
Currently creating an automation using zapier which should change the lead owner in salesforce when the event takes place. It successfully reaches salesforce but does not actually change the "lead owner" but it is instead reflected in the lead history section. There is no clear salesforce workflow or rule in place which should prevent this automation from occurring.
When the automation executes as you can see above, the lead owner successfully changes in the lead history but it does not actually change the lead owner of the actual lead so we are manually having to go back and change this.
Has anybody else faced similar issues when working with the salesforce API when changing the lead owner and if so what was the solution?
Check Lead assignment rules. It's separate area in Setup, different from workflows, flows, process builder and triggers.
You probably have an active rule that runs on update, not only on insert. Your API call works OK, changes the OwnerId field but then the assignment rule overwrites that. That's why you see it as 2 entries in history.
You can also confirm what's going on byenabling debug logging on the integration user and check if it captures anything.
Optionally you could also suppress the assignment rule during the update. This is... questionable. I mean talk with your SF admin first, if you suppress the rule then you moved bit of logic out of salesforce. 2 months later nobody will remember why something doesn't fire, it's cleaner to just modify the rule to skip these records.
If Zapier uses SF REST API there's a HTTP header it should send, Sforce-Auto-Assign: FALSE. If it uses SOAP API - similar thing will have to be set in the SOAP message's header, check the WSDL for exact syntax?
We solved this, just broke down the issue and resolved by doing the following (This was beyond the standard salesforce scope of support as we use custom prefill URL's for anybody wondering):
Create a new hidden field called something such as 'tmp_owner'
Assign the new lead owner ID to a new text field called 'tmp_owner' which is hidden on
the lead field to other salesforce org users
Added a salesforce workflow rule when this 'tmp_owner' is populated replace the 'lead owner' field with the data.
I'm looking to use AtTask's API to update or create a custom field (ie. assign a custom ID apart from AtTask's auto-generated id) whenever a project is created through the web app. But I have not found anything about handling events in the API documentation.
I'm able to retrieve/edit project fields when issuing a request by ID or some other search parameter.
But I'm having trouble finding ways to edit project fields on some event like 'project created'.
One way I can think of is to have my script periodically search for new projects based on project metadata and edit projects that way, but there must be a better solution I probably missed.
Thanks in advance!
UPDATE:
It seems 'AtTask event subscriptions' was what I was looking for. At the time of the post below (12/2013), due to scalability issues, AtTask has turned this feature turned off with no ETA on resolving the issue. See here: Does AtTask event subscription work?
Any updates would be appreciated.
You are correct the AtTask API does not currently support events. The easiest thing to do is to just poll the system for updates using the search. You could also monitor an email address for emails that are sent upon project creation. The email will contain the project/task/issue ID that you can use to update events.