Error with targeted_entities - facebook-graph-api

I need to set targeted_entities param in targeting for the creatives with type 31
targeted_entities = [100003297600281, 100000529832243]
on my request I got an error message fom Graph
(#100) Invalid Targeted Entity IDs -- The targeted entity ids are invalid
Why user ID 100003297600281 is invalid? If i send 100000529832243 - all OK

Related

Updating Sales Order line items in Dynamics business central

I have a sales order created using API for business central. Sales order has a single line item. I want to update the quantity of line item. Following is what I have tried so far.
Endpoint: https://api.businesscentral.dynamics.com/v1.0/domain.com/api/v1.0/companies(company_id)/salesOrders(sales_order_ide)/salesOrderLines(sales_order_line_id)
where sales order line id is of the form e86d3aa1-f2f8-ea11-aa61-0022481e3b8c-10000
as described in this document When a PATCH request is made, I get the following exception:
')' or ',' expected at position 9 in
'(sale-order-line-item-id)'.
The exception stated above was also occuring when i was simply trying to get the line item but that was fixed when I changed the URL and it took the form:
Endpoint:
https://api.businesscentral.dynamics.com/v1.0/domain.com/api/v1.0/companies(b4a4beb2-2d42-40dc-9229-5b5c371be4e3)/salesOrders(e86d3aa1-f2f8-ea11-aa61-0022481e3b8c)/salesOrderLines?filter=sequence eq 10000
This endpoint is returning correct response when i try to get the line item by issuing
GET request. However, when I issue a PATCH request using the same endpoint, with a simple request body e.g.
{"quantity" : 2.0}
it throws the exception:
'PATCH' requests for 'salesOrderLines' of EdmType 'Collection' are not
allowed within Dynamics 365 Business Central OData web services.
I am also specifying the if-Match header along with the request that contains etag value for the line item but of no avail and same exception is occurring. Am I missing something? Any help will be appreciated.
For those who may visit this question later, after much hit and trial through Postman, I finally figured out the problem. In my case if-Match header that's basically is Etag for the line item is all fine. The Problem was with API URL, specifically the way we specify the line item id. We have to specify this in single quotes so the URL for API call becomes:
https://api.businesscentral.dynamics.com/v1.0/domain.com/api/v1.0/companies(company_id)/salesOrders(sales_order_ide)/salesOrderLines('sales_order_line_id')
You would note that we are not specifying company_id and sales_order_id in single quotes, reason being, both of these parameters a of type GUID whereas sales_order_line_id is of type string as per metadata document.
I am getting below error
{
"error": {
"code": "BadRequest_NotFound",
"message": "Bad Request - Error in query syntax."
}
}

AWS SES, sending mail with an unverified 'from'

I'm trying to create a discussion list sender using SES. The 'receive' part is fine, but when I send, I want to preserve the user's "from" address. Aside from some subject rewriting, here's what I'm doing to the headers; VERIFIED_FROM is my mailing list alias. This is py3.6, but it shouldn't matter.
msg['Reply-To'] = VERIFIED_FROM_EMAIL
msg['Return-Path'] = VERIFIED_FROM_EMAIL
When I call sendRawEmail, I get an error like this, brackets for scrubbed entries:
[ERROR] [timestamp] [request id] Client error while forwarding email for <[VERIFIED_FROM_EMAIL]> to <[all emails on list]>: An error occurred (MessageRejected) when calling the SendRawEmail operation: Email address is not verified. The following identities failed the check in region US-WEST-2: ["user who sent the message" user#domain.com]
I can't put all users on the verified list. I could set the 'from' to my list address, but then I lose the identity of the sender.
I'm sure this has been done with SES- but how?
The reply-to field and the return-path field are fields that require a validated email address. [1]
With each email you relay, you can create a unique email address for people to reply to (e.g. abcdef123#yourdomain.com) which you can then relay back to the same threads using the Message-ID and In-Reply-To headers.
You can also modify what the name looks like for the message using the Name <email#yourdomain.com> header too.
[1] https://forums.aws.amazon.com/message.jspa?messageID=221703

Get a error message "An unknown error has occurred" when create ad set

I use java sdk(v2.9) to create ad set, and get this error message.
{"error":{"message":"An unknown error has occurred.","type":"OAuthException","code":1,"fbtrace_id":""}}
This is my code:
AdPromotedObject promotedObject = new AdPromotedObject();
promotedObject.setFieldApplicationId("1620089638283287");
account.createAdSet()
.setName("AdSet01")
.setBillingEvent(AdSet.EnumBillingEvent.VALUE_APP_INSTALLS)
.setBidAmount(2L)
.setDailyBudget(1000L)
.setPromotedObject(promotedObject)
.setCampaignId("23842591178760207")
.setTargeting(
new Targeting()
.setFieldGeoLocations(new TargetingGeoLocation().setFieldCountries(Arrays.asList("US")))
)
.setStatus(AdSet.EnumStatus.VALUE_PAUSED)
.execute();
Campaign id and app id is both exists and valid. I use the account create a campaign successfully so it is a valid account.
I found the problem, i miss object_store_url field for promotedObject.
promotedObject.setFieldObjectStoreUrl("app url");

Cannot find an attribute ID for an element RequestorID for added SOAP (wsdl)

I have planned to consume Bargain Max Finder Sabre SOAP API. In Response it shows me two errors.
1.cvc-complex-type.4: Attribute 'ID' must appear on element 'RequestorID , Code:INVALIDREQ
Error Code: ttfhlp684 , Type: Server, Value:TOMCA
Instead of Attribute 'ID' i have ID_Context. How to fix these two problems?

Handling errors with the (now default) Ember Data JSON-API adapter

I am using Ember 1.13.7 and Ember Data 1.13.8, which by default use the JSON-API standard to format the payloads sent to and received from the API.
I would like to use Ember Data's built-in error handling in order to display red "error" form fields to the user. I have formatted my API error responses as per the JSON-API standard, e.g.
{"errors":[
{
"title":"The included.1.attributes.street name field is required.",
"code":"API_ERR",
"status":"400",
}
]}
and when I attempt to save my model the error callback is being correctly executed. If I look within the Ember Inspector I can see that the model's "isError" value is set to true but I can't see how Ember Data is supposed to know which field within the model is the one in an error state? I see from the official JSON-API pages (http://jsonapi.org/format/#errors) that you can include a "source" object within the error response:
source: an object containing references to the source of the error,
optionally including any of the following members:
pointer: a JSON Pointer [RFC6901] to the associated entity in the request document
[e.g. "/data" for a primary data object, or "/data/attributes/title"
for a specific attribute].
parameter: a string indicating which query
parameter caused the error.
but is this what I should be doing in order to tell Ember Data which fields it should mark as being in an error state?
If anyone can help shed some light on this I'd be grateful.
Thanks.
Note the answer below is based on the following versions:
DEBUG: -------------------------------
ember.debug.js:5442DEBUG: Ember : 1.13.8
ember.debug.js:5442DEBUG: Ember Data : 1.13.9
ember.debug.js:5442DEBUG: jQuery : 1.11.3
DEBUG: -------------------------------
The error handling documentation is unfortunately scattered around at the moment as the way you handle errors for the different adapters (Active, REST, JSON) are all a bit different.
In your case you want to handle validation errors for your form which probably means validation errors. The format for errors as specified by the JSON API can be found here: http://jsonapi.org/format/#error-objects
You'll notice that the API only specifies that errors are returned in a top level array keyed by errors and all other error attributes are optional. So seemingly all that JSON API requires is the following:
{
"errors": [
{}
]
}
Of course that won't really do anything so for errors to work out of the box with Ember Data and the JSONAPIAdapter you will need to include at a minimum the detail attribute and the source/pointer attribute. The detail attribute is what gets set as the error message and the source/pointer attribute lets Ember Data figure out which attribute in the model is causing the problem. So a valid JSON API error object as required by Ember Data (if you're using the JSONAPI which is now the default) is something like this:
{
"errors": [
{
"detail": "The attribute `is-admin` is required",
"source": {
"pointer": "data/attributes/is-admin"
}
}
]
}
Note that detail is not plural (a common mistake for me) and that the value for source/pointer should not include a leading forward slash and the attribute name should be dasherized.
Finally, you must return your validation error using the HTTP Code 422 which means "Unprocessable Entity". If you do not return a 422 code then by default Ember Data will return an AdapterError and will not set the error messages on the model's errors hash. This bit me for a while because I was using the HTTP Code 400 (Bad Request) to return validation errors to the client.
The way ember data differentiates the two types of errors is that a validation error returns an InvalidError object (http://emberjs.com/api/data/classes/DS.InvalidError.html). This will cause the errors hash on the model to be set but will not set the isError flag to true (not sure why this is the case but it is documented here: http://emberjs.com/api/data/classes/DS.Model.html#property_isError). By default an HTTP error code other than 422 will result in an AdapterError being returned and the isError flag set to true. In both cases, the promise's reject handler will be called.
model.save().then(function(){
// yay! it worked
}, function(){
// it failed for some reason possibly a Bad Request (400)
// possibly a validation error (422)
}
By default if the HTTP code returned is a 422 and you have the correct JSON API error format then you can access the error messages by accessing the model's errors hash where the hash keys are your attribute names. The hash is keyed on the attribute name in the camelcase format.
For example, in our above json-api error example, if there is an error on is-admin your would access that error like this:
model.get('errors.isAdmin');
This will return an array containing error objects where the format is like this:
[
{
"attribute": "isAdmin",
"message": "The attribute `is-admin` is required"
}
]
Essentially detail is mapped to message and source/pointer is mapped to attribute. An array is returned in case you have multiple validation errors on a single attribute (JSON API allows you to return multiple validation errors rather than returning just the first validation to fail). You can use the error values directly in a template like this:
{{#each model.errors.isAdmin as |error|}}
<div class="error">
{{error.message}}
</div>
{{/each}}
If there are no errors then the above won't display anything so it works nicely for doing form validation messages.
If you API does not use the HTTP 422 code for validation errors (e.g., if it uses 400) then you can change the default behavior of the JSONAPIAdapter by overriding the handleResponse method in your custom adapter. Here is an example that returns a new InvalidError object for any HTTP response status code that is 400.
import DS from "ember-data";
import Ember from "ember";
export default DS.JSONAPIAdapter.extend({
handleResponse: function(status, headers, payload){
if(status === 400 && payload.errors){
return new DS.InvalidError(payload.errors);
}
return this._super(...arguments);
}
});
In the above example I'm checking to see if the HTTP status is 400 and making sure an errors property exists. If it does, then I create a new DS.InvalidError and return that. This will result in the same behavior as the default behavior that expects a 422 HTTP status code (i.e., your JSON API error will be processed and the message put into the errors hash on the model).