We are creating a Salesforce API and only want to import Xero Invoices that relate to certain account codes. We don't want every Xero contact and Xero invoice in the system.
At present, we call a page of invoices and then loop over the line items in each invoice them and only insert the Invoices that contain the accound codes we are looking for.
This is not an efficient process. So I wanted to check with the XeroAPI gurus are there are any filters I can apply to the GET call?
Sorry but there's no way to filter invoices on any of the line item level attributes (account, tracking, item etc). You'll have to continue looping through them all.
If you're not doing so already, I'd advise using the if-modified-since header so you're only looping through what's changed since your previous call but you still need to do it for all invoices.
Related
When using the NetSuite SOAP API I would like to retrieve the purchaseOrderList for a VendorBill record. The purchaseOrderList field is shown as a RecordRefList on this docs page, however that field doesn't populate on responses when performing a get to retrieve a vendorBill based on the internalId.
I've tried setting the bodyFieldsOnly header to false, hoping this would cause it to return all related fields, however this doesn't change the response.
Does anyone know how to force a RecordRefList field type to populate?
After searching through the docs online it seems that the purchaseOrderList property on the Vendor Bill is only used when updating the bill to associate it with Purchase Orders, it doesn't look like the property can be returned when retrieving Vendor Bill records. See this docs page under the 'Linking Purchase Orders to a Vendor Bill' section.
In order to retrieve the PO numbers associated with a Vendor Bills items and expenses I am retrieving them from the itemList and expenseList properties which are present on the Vendor Bill. If anyone knows of another way please feel free to comment or edit.
I have a column of hundreds of parcel tracking numbers, and I want to use the parcel carrier's REST API to pull some of the tracking information (promised delivery date, and actual delivery date) and then use conventional spreadsheet techniques on it.
Is there a simple way to put the REST call in a formula in an excel cell? in pseudocode it would be call this REST url, using the tracking number in the cell to the left as an argument, and here's the authentication user/password, and return the value in the response field 'deliveryDate'
I am intrigued by Power Query and I figured out how to use Power Query to do it for a static REST url with the tracking number manually filled in, but I don't know how to make PQ do it for hundreds of items.
or maybe there is an online tool for building this function with lego blocks for a caveman like myself?
since shopify's transaction reporting is broken, I'm trying to use the API to get transaction fees for orders and basic accounting. In their API docs, they have their endpoints and parameters listed for getting/posting transactions. To "Receive a list of all Transactions", the docs say
GET /admin/orders/#{id}/transactions.json
but don't explain what the #{id} is for. The call will only work if I put a transaction ID in, but then it only shows a single transaction, rather than a list. The docs state that to "Get the Representation of a specific transaction":
GET /admin/orders/#{id}/transactions/#{id}.json
Which has the id in there twice. I can't use a single transaction, I need all of them for a specific range. I've tried /admin/orders/transactions.json, or putting in all or * in for the id, and it returns errors unless the id is a valid transaction id. Any ideas?
Transactions belong to an order. So the ID you are wondering about is for one specific order. So if you want transactions for your accounting system, the important thing you're basing your API work on will be orders. So setup your code to first off download the orders of interest. Say for a month. Now for each order ask for the transactions, and produce your report.
The repository in the CommonDomain only exposes the "GetById()". So what to do if my Handler needs a list of Customers for example?
On face value of your question, if you needed to perform operations on multiple aggregates, you would just provide the ID's of each aggregate in your command (which the client would obtain from the query side), then you get each aggregate from the repository.
However, looking at one of your comments in response to another answer I see what you are actually referring to is set based validation.
This very question has raised quite a lot debate about how to do this, and Greg Young has written an blog post on it.
The classic question is 'how do I check that the username hasn't already been used when processing my 'CreateUserCommand'. I believe the suggested approach is to assume that the client has already done this check by asking the query side before issuing the command. When the user aggregate is created the UserCreatedEvent will be raised and handled by the query side. Here, the insert query will fail (either because of a check or unique constraint in the DB), and a compensating command would be issued, which would delete the newly created aggregate and perhaps email the user telling them the username is already taken.
The main point is, you assume that the client has done the check. I know this is approach is difficult to grasp at first - but it's the nature of eventual consistency.
Also you might want to read this other question which is similar, and contains some wise words from Udi Dahan.
In the classic event sourcing model, queries like get all customers would be carried out by a separate query handler which listens to all events in the domain and builds a query model to satisfy the relevant questions.
If you need to query customers by last name, for instance, you could listen to all customer created and customer name change events and just update one table of last-name to customer-id pairs. You could hold other information relevant to the UI that is showing the data, or you could simply hold IDs and go to the repository for the relevant customers in order to work further with them.
You don't need list of customers in your handler. Each aggregate MUST be processed in its own transaction. If you want to show this list to user - just build appropriate view.
Your command needs to contain the id of the aggregate root it should operate on.
This id will be looked up by the client sending the command using a view in your readmodel. This view will be populated with data from the events that your AR emits.
Given that we provide a restful api that serves book entities listening at
/books
And a client can get a book at the usual
GET /books/{id}
Suppose that we want to begin offering discounts on books to only our most vigilant buyers. These buyers would be given a discount code, and that code will reduce the price of the book.
Thus, a generic response may be
GET /books/4
{"id":4, "price":"24.95"}
Where a response to a query with a discount code may be
GET /books/4
{"id":4, "price":"24.95", "yourPrice":"19.95"}
The back-end processing we can get figured out, but what is the best practice for a client submitting a discount code over a restful api?
Certain books will be eligible for discounts while others will not. Discounts will not be broad (20% off everything), but instead will map to a specific price for that particular code (or client/code combo).
We've considered:
kludging the url
GET /codes/{someCode}/books/{id}
Adding the code in a header value
Using a query string
GET /books?code=myCode
anything else?
EDIT: Our goal is not to implement single-use codes. Instead, these discount codes could be used some fixed number of times for some fixed set of books.
I like using query variables. I just looked at the RESTful Web Services book, my main reference in this area, and they say:
Use query variables only to suggest
arguments being plugged into an
algorithm... If two URIs differ only
in their query variables, it implies
they're the different sets of inputs
into the same underlying algorithm.
It seems to me your discount codes are inputs to a discounting algorithm.
Charles
If you're going to be submitting anything that's not idempotent, I would suggest using POST instead of GET. You wouldn't want a client to be able to use their code more than once.
Anything you add in the URL or header values are open to be intercepted, and possibly allowing other users to 'fake' their discount ID. 1 approach would be to introduce a new POST call, that will allow the ID to be encrypted with simple HTTPS. The POSTed data could be as simple as the discountID or customerID.
Added - Sorry Michael, you already said that :)
You can register the code in a table so when the user retrieves that book automatically returns that book with the proper discount, for example:
The user can add some code
POST /register/{code}
This will add an entry to a table {user} - {code} so when the user retrieves by
GET /books/{id}
will use that entry to apply the discount. I'm guessing that you already have some relation between {code}-{book} so wont get into that.