I am trying to extract a large amount of details out of our Eloqua system using it's API and got this API to work perfectly for single IDs: https://docs.oracle.com/en/cloud/saas/marketing/eloqua-rest-api/op-api-rest-1.0-data-contact-id-get.html
The problem is that I need to run this for a large number of IDs and it will require alot in order to run it for the entire population. Is there any bulk APIs that can extract all of the following details out of Eloqua/Contact for the entire population? I don't see any on that pages documentation that meet this need under the Bulk section.
contactid, company, employees, company_revenue, business_phone, email_address, web_domain, date_created, date_modified, address_1, address_2, city, state_or_province, zip_or_postal_code, mobile_phone, first_name, last_name, title
It's a multi-step process with the Bulk API, typically in the following fashion:
Get a list of the current internal field names - useful for creating your export definition
Create an export definition and post it here. There is a useful example on the page, you do not need a filter criteria. Store the export ID somewhere
Using your export definition id, create a sync. It will gather the data in the background and prepare it for you. Take note of the sync ID provided in the initial response.
Check on the sync status with your sync ID here. It should only take a couple of minutes - and there is a callback url option as well in the previous step, if you don't want to keep polling.
Once your data is ready, use that sync id and request the data. Depending on how many rows were retrieved, you might need to paginate through the results using the offset query param. By default it will give you JSON, but I usually choose CSV (specify in the header).
If you need updated data, feel free to create a new sync using the same export definition id. You do not need to create a new export definition each time.
Related
I'm on a project in which I need to get data from a ServiceNow instance and treat all data with PowerBI. I'm able to retrieve a big amount of data (Snow collect a lot of data), but I still need a way to filter data correctly. I'm calling to this URL:
Besides, I want also to apply a filter to retrieve just some specific registries from the table Requested Items. For that, I use the sysparm_query parameter to filter the field "cmdb_ci" and more specifically it's "name", something like:
&sysparm_query=cmdb_ci=What I need to Filter
Apart from this, I have also tried:
&sysparm_query=cmdb_ci.value=What I need to Filter
&sysparm_query=cmdb_ci.display_value=What I need to Filter
&sysparm_query=cmdb_ci.sys_id=What I need to Filter
&sysparm_query=cmdb_ci.name=What I need to Filter
But still not found the solution... as all these does not respond the solution needed.
Does someone know how I can manage this?
Thanks!!
JLG
There are two "Configuration item" fields in sc_req_item: cmdb_ci and configuration_item. Make sure that you are using the correct one. Either cmdb_ci.name=value or configuration_item.name=value should work, depending on which of the two fields you are using. cmdb_ci.value and cmdb_ci.display_value will not work as there are no fields on the record with these names. cmdb_ci.sys_id should work if you are supplying a sys_id (although it is redundant to type .sys_id for a reference field).
You should first verify your query through the ServiceNow UI before attempting to use it in an API call.
Type sc_req_item.list in the Filter navigator
On the filter list select "Show related fields"
Get your filter to work correctly
Right-click on the filter and select "Copy query"
The next step is to test it using the REST API Explorer.
Final step is to configure your client tool (PowerBI).
I'm trying to fetch details from VSTS using VSTS query API. So to get all Portfolio Epics I created a custom query and used its ID to get that in JSON format. the query looks like this
https://dev.azure.com/{organization}/{project}/{team}/_apis/wit/wiql/{id}?api-version=5.0-preview.2
But the issue is its not giving me many details about each of the work items in JSON. It only lists the ID and URL. Like this
WorkItems:[
{ID:234,URL:"workitemurl"},
{ID:235,URL:"workitemurl"},
{ID:236,URL:"workitemurl"},
...
]
So if I need more details about an item I need to execute those individual URl for each PE and thus I can get its details. instead of I am just checking is there is any way of getting an ID (keyedinID of each work item along with the ID and URL) like this. Please note KID is a field if we execute the URL separately. So to avoid that extra process, I would like to get that along with the WorkItems.
WorkItems:[
{ID:234,URL:"workitemurl",KID:002},
{ID:235,URL:"workitemurl",KID:023},
{ID:236,URL:"workitemurl",KID:033},
...
]
So how can we make this possible?
The Web UI uses a different API to get query results (/_api/_wit/_query), which allows query+data in a single pass. This is an old __v5 type call, which means it's considered internal.
The proper way to do this now is to first do the query as you're doing it right now and then call /_api/wit/workitems?ids=1,2,3,4 using the IDs from the references you got from the first call. That will also allow you to load the details dynamically and in small batches which will result in a more responsive UI.
See:
https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/list?view=azure-devops-rest-4.1
I want to generate an IDOC file to make shop orders availabe to the R/3 SAP System. My question is concerning BELNR in E2EDK01. As we dont have the possibility to use Webservices and BAPI, we only make the data available via files.
Actual questions are:
Do i yet need a [BELNR] in the IDOC file?
If yes, where to get this [BELNR] from?
E2EDK01-BELNR is the order number of the ordering party, normally it is not needed, but useful.
Example:
The customer sends an order and is unsure if the order received you. So he sends the order again. Now you have two similar orders. You can't know, if there are two similar orders or if you have two idocs for the same order.
If E2EDK01-BELNR is filled with the order number of the customer system, you can decide how to proceed (e.g. ignore the 2nd idoc).
If I understand your question correct, you create the order out of your shop system. You could offer an (optional) field like 'Your order number' and use this. If the same order number (per customer) is used again you can make a warning ("Order X is already ordered").
If you don't want this field you could use the session id to identify double postings.
I'm creating an app that uses core data to store information from a web server. When there's an internet connection, the app will check if there are any changes in the entries and update them. Now, I'm wondering which is the best way to go about it. Each entry in my database has a last updated timestamp. Which of these 2 will be more efficient:
Go through all entries and check the timestamp to see which entry needs to be updated.
Delete the whole entity and re-download everything again.
Sorry if this seems like an obvious question and thanks!
I'd say option 1 would be most efficient, as there is rarely a case where downloading everything (especially in a large database with large amounts of data) is more efficient than only downloading the parts that you need.
I recently did something similiar.
I solve the problem, by assigning an unique ID and a global 'updated timestamp' and thinking about 'delta' change.
I explain better, I have a global 'latest update' variable stored in user preferences, with a default value of 01/01/2010.
This is roughly my JSON service:
response: {
metadata: {latestUpdate: 2013...ecc}
entities: {....}
}
Then, this is what's going on:
pass the 'latest update' to the web service and retrieve a list of entities
update the core data store
if everything went fine with core data, the 'latestUpdate' from the service metadata became my new 'latest update variable' stored in user preferences
That's it. I am only retrieving the needed change, and of course the web service is structured to deliver a proper list. Which is: a web service backed by a database, can deal with this matter quite well, and leave the iphone to be a 'simple client' only.
But I have to say that for small amount of data, it is still quite performant (and more bug free) to download the whole list at each request.
As per our discussion in the comments above, you can model your core data object entries with version control like this
CoreDataEntityPerson:
name : String
name_version : int
image : BinaryData
image_version : int
You can now model the server xml in the following way:
<person>
<name>michael</name>
<name_version>1</name_version>
<image>string_converted_imageData</image>
<image_version>1</image_version>
</person>
Now, you can follow the following steps :
When the response arrives and you parse it, you initially create a new object from entity and fill the data directly.
Next time, when you perform an update on the server, you increase the version count of an entry by 1 and store it.
E.g. lets say the name michael is now changed to abraham, then version count of name_version on server will be 2
This updated version count will come in the response data.
Now, while storing the data in the same object, if you find the version count to be same, then the data update of that entry can be skipped, but if you find the version count to be changed, then the update of that entry needs to be done.
This way you can efficiently perform check on each entry and perform updates only on the changed entries.
Advice:
The above approach works best when you're dealing with large amount of data updation.
In case of simple text entries for an object, simple overwrite of data on all entries is efficient enough. And this also keeps the data reponse model simple.
How can i add custom attributes/data to Task via API . for example we wanted to add field like customer contact number or deal amount e.t.c
We don't currently support adding arbitrary metadata to tasks, though it's something we're thinking about. In the meantime, what many customers do is to simply put data in the note field in an easily-parseable form, which works well and also lets humans reading the task see the e.g. ticket number.
It's not a terribly elegant solution, but it works.
https://asana.com/developers/documentation/getting-started/custom-external_data
Custom external data allows a client application to add app-specific metadata to Tasks in the API. The custom data includes a string id that can be used to retrieve objects and a data blob that can store character strings.
See the external field at https://asana.com/developers/api-reference/tasks