I am doing an integration project for a customer running Microsoft Exchange 2007 (BPOS). I am looking for a way to search for e-mail using the Exchange Web Services Operations -- MS' API to their own hosted exchange solution. So far, I have found a nice API description, but as far as I can see none of it allows for searching for e-mails using different criteria. In this case, I need to find all e-mails that contains a specific sender or recipient identified by an e-mail address.
Could you provide me with guidance on how to do this? Thanks.
In my (admittedly minimal) experience with Exchange Web Services, the only way to do this would be to retrieve all items in a folder and scan through their properties.
You need to specify which properties are retrieved when you call the FindItem() operation.
PathToUnindexedFieldType fieldTypePath = new PathToUnindexedFieldType();
fieldTypePath.FieldURI = UnindexedFieldURIType.folderDisplayName;
GetFolderType folderType = new GetFolderType();
folderType.FolderShape = new FolderResponseShapeType();
folderType.FolderShape.BaseShape = DefaultShapeNamesType.IdOnly;
folderType.FolderShape.AdditionalProperties = new BasePathToElementType[1];
folderType.FolderShape.AdditionalProperties[0] = fieldTypePath;
So the only saving grace is that you don't need to retrieve the full email body etc - just the fields you explicitly require.
Related
I just try with AWS cognito for authentication my web application.
I am using Warrant library https://github.com/capless/warrant
I have many users which belong to my group (Ex: G1, G2, G3)
However, I cannot find the way to get list of users for specific group.
Can anyone tell me how to get list users in specific group?
Thank in advance.
I've just passed by the same situation as you, because I'm using warrant to. The problem is that warrant is an high level library, so it doesn't have capacity to manipulate all features that cognito can provide.
So, if you can try to solve this problem without using warrant, my solution is to use boto3 identity provider api, an low level feature that works with various usefull features of cognito.
Check these low level functions in AWS API documentation
So, using these functionalities, I made the code bellow to list all users at some group:
import boto3
cognito_cl = boto3.client('cognito-idp')
res = cognito_cl.list_users_in_group(
UserPoolId=<some_pool_id>,
GroupName=<some_group_name>
)
group_users = res.get('Users', 'empty')
Then, if you access group_users variable, you can see the list of all users in this group, just like all of their attributes.
Hope that I have helped you even after so long.
I am looking for a way to access emails in Exchange. I assume that there would be needed 2007 version with SP1. As I know there is possibility to access Exchange by PowerShell or by web services. What I am interested in is to access messages from various mailboxes to get their from/to/subject/body.
I've found that by web services this is possible by using FindItem and GetItem calls. Are there also other powershell commands to get to emails?
How can I access what I need?
You should use the Exchange API for this (EWS)
Glenn Scales has explained how to use it with powershell on http://gsexdev.blogspot.nl/2012/01/ews-managed-api-and-powershell-how-to.html?m=1
I looked over the native Exchange cmdlets and was only able to find a reference to Get-Message cmdlet, but it appears that cmdlet is used to
view the details of one or more messages in a queue on a computer that has the Hub Transport server role or the Edge Transport server role installed.
But it doesn't look like the message body is returned.
If you can tolerate a paid solution (currently in Beta), my employer (CData Software) makes a set of cmdlets for working with Exchange data.
EDIT: Beta solution isn't helpful for OP.
With the limitations in the native Exchange cmdlets and the restriction for a production solution, I can offer my employer's ADO.NET Provider for Exchange. We have already published a Knowledge Base article (whose contents are copied below):
The CData ADO.NET Provider for Microsoft Exchange implements standard ADO.NET interfaces, enabling you to access the capabilities of the Microsoft Exchange API from .NET applications, such as PowerShell. The provider simplifies authentication and interaction with Microsoft Exchange data. This tutorial shows how to use some of the common ADO.NET objects to execute SQL queries directly from PowerShell.
Execute Queries
Follow the three steps below to execute any create, read, update, and delete (CRUD) command to Microsoft Exchange data in PowerShell:
Load the provider's assembly:
[Reflection.Assembly]::LoadFile("C:\Program Files\CData\CData ADO.NET Provider for Microsoft Exchange\lib\System.Data.CData.Exchange.dll")
Connect to Microsoft Exchange data. Specify the User and Password to connect to Exchange. Additionally, specify the address of the Exchange server you are connecting to and the Platform associated with the server.
$constr = "User='myUser#mydomain.onmicrosoft.com';Password='myPassword';Server='https://outlook.office365.com/EWS/Exchange.asmx';Platform='Exchange_Online';"
$conn= New-Object System.Data.CData.Exchange.ExchangeConnection($constr)
$conn.Open()
Instantiate the ExchangeDataAdapter, execute an SQL query, and output the results:
$sql="SELECT GivenName, Size from Contacts"
$da= New-Object System.Data.CData.Exchange.ExchangeDataAdapter($sql, $conn)
$dt= New-Object System.Data.DataTable
$da.Fill($dt)
$dt.Rows | foreach {
Write-Host $_.givenname $_.size
}
Update Microsoft Exchange Data
$cmd = New-Object System.Data.CData.Exchange.ExchangeCommand("UPDATE Contacts SET BusinnessAddress_City='Raleigh' WHERE Id = #myId", $conn)
$cmd.Parameters.Add(new System.Data.CData.Exchange.ExchangeParameter("myId","10456255-0015501366"))
$cmd.ExecuteNonQuery()
Insert Microsoft Exchange Data
$cmd = New-Object System.Data.CData.Exchange.ExchangeCommand("INSERT INTO Contacts SET BusinnessAddress_City='Raleigh' WHERE Id", $conn)
$cmd.Parameters.Add(new System.Data.CData.Exchange.Microsoft ExchangeParameter("myId","001d000000YBRseAAH"))
$cmd.ExecuteNonQuery()
Delete Microsoft Exchange Data
$cmd = New-Object System.Data.CData.Exchange.ExchangeCommand("DELETE FROM Contacts WHERE Id", $conn)
$cmd.Parameters.Add(new System.Data.CData.Exchange.Microsoft ExchangeParameter("myId","001d000000YBRseAAH"))
$cmd.ExecuteNonQuery()
In this question Worklight: Push notification without User ID, the given answer was to subscribe a persistent cookie userID with the event source.. my question is: How can I do this? how can I use the userID given by the cookie ( I already got the userID ) to subscribe to my eventSource? Can't seem to find this anywhere on the internet
There is are additional questions you need to ask yourself, before looking into what you wrote.
Are you using Worklight 6.2 or above?
Are you looking to send generic information (i.e. not sensitive, per-user data (like bank account balance and the like))?
If the answer is 'yes' for both of the above, do not bother yourself with event source-based notifications. Instead, use either broadcast or tag-based notifications (tags = "topics of interest"). Using this approach does not require any additional work on your part other than actually sending the notification.
You can take a look at the documentation:
Developer Center: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-6-3/notifications/push-notifications-hybrid-applications/
Knowledge Center: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.dev.doc/devref/t_tag-based_notifications_setting_up.html
In the following answer you can find an example for broadcast notifications (broadcast notification is a form of tag-based notifications): https://stackoverflow.com/a/27881423/1530814
I am developing a integration between a desktop application and Amazon MWS and need to be able to offer users a choice of categories to put the product they are listing into. My problem is that I can't find any way of programmatically getting the current categories from MWS using the API.
Additionally once I have a category reference to use I will need a way to the pull in and add the category specific XML child of ProductData (eg Home, Jewelry, Computers, etc) but they don't seem to be linked in any well defined way. For example, I can't say "if the chosen category is reference nnnnn ask them to populate the Computers specific ProductData", unless I write something myself to map them.
Has anyone else come across these problems and found a workable solution?
Any help appreciated...
I am currently exploring the option of limiting users to only selling products already listed on Amazon but still can't figure out how to pull in the correct category specific XML.
There are various product look-ups but they all seem to work from either my SKU (which will not yet be there) or Amazons ASIN (which I don't yet know)
You can use amazon advertizement api for this.
You have to create account on amazon affiliate programme.From that you have to get security credentials also .
After That go to BrowseNode Tree Page and download root categories list and save it to file or database.From there you get categoryname and their browseNodeId.
Then call BrowseNodeApi to get Child Categories for parent Category.
Please Follow This Link
http://docs.aws.amazon.com/AWSECommerceService/latest/DG/ProgrammingGuide.html
code for calling BrowseNodeApi
SignedRequestHelper helper =
new SignedRequestHelper(appConfig["AWSAccessKey"], appConfig["AWSSecretKey"], appConfig["endpoint"]);
string url = helper.Sign("http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService&Operation=BrowseNodeLookup&BrowseNodeId=" + value + "&AssociateTag=beginners00-00&Version=2011-08-01");
HttpWebRequest request = WebRequest.Create(url) as HttpWebRequest;
// Get response
using (HttpWebResponse response = request.GetResponse() as HttpWebResponse)
{
}
and also download SignatureGenerator class HMAC
I'm fairly new to REST web services and very used to RPC. I know the advantages of REST by reading several posts like this one.
I am developing the server in django using django-rest-framework.
Although have this question (or questions):
I have this model:
class Poll(models.Model):
questionString = models.CharField(max_length=500, blank=True)
timeToAnswer = models.IntegerField(default=30)
startDate = models.DateTimeField(null=True, db_column='startDate', blank=True)
token = models.CharField(max_length=20, blank=True, unique=True)
class PollAggregator(models.Model):
name = models.CharField(max_length=135)
description = models.CharField(max_length=500, blank=True)
votersToken = models.CharField(max_length=20, null=True, blank=True)
class PollPollAggregatorRel(models.Model):
pollAggregator = models.ForeignKey(PollAggregator, null=True, db_column='pollAggregatorId', blank=True)
poll = models.ForeignKey(Poll, null=True, db_column='pollId', blank=True)
So I can have a single poll or I can have a bunch of polls aggregated in a poll aggregator (i.e. room).
So I created the rest calls: pollList, pollDetail, pollAggregatorList, pollAggregatorDetail. But I have problems to design for PollPollAgregatorRel.
Of course I can have PollPollAgregatorRelList and PollPollAgregatorRelDetail and make the normal post, get, update, delete. So if I want to make a new relation between a poll and poll aggregator in REST style, I do:
Check if PollPollAgregator (list) exists with the poll id with a get and filtered by pollId
If so, I update this item to have my new pollAggregator id
If not I create a new PollPollAgregator with a post
My first question is is there any easier and simpler way to do this?
If I use a RPC like web service I do something like:
Relate poll with pollAggregator and use a get_or_create for PollPollAggregatorRel. So I update or create a new PollPollAggregatorRel object.
So using RPC like, the client uses only one call versus REST that needs to call 2 times. In this case seems to be much simpler to use RPC for both server and client side.
Second question is: Is it bad practice to use both REST and RPC in the same API?
Q1: I think it would be reasonable to provide a REST-style POST operation that either returns an existing aggregator or creates a new one as required. Which, logically, seems not unlike your "RPC" service.
I think part of your difficulty may be that you are designing your REST "calls" (hint: they're not "calls", they're "resources") too closely around the underlying model. It's a mistake I've made in the past.
REST != CRUD.
A key benefit of REST is that it allows the interface to be separated from the model, so the server can change its implementation without affecting clients. Another key benefit is that it minimizes the amount of information the client needs to know in advance in order to perform some operation. E.g. a REST client should be able to discover all the resource URIs it needs to use by interacting with the "front resource" (by analogy with "front page") of the service.
So I would consider an approach in which there the following resources cover what you describe above:
a service home page, whose representation contains links (or link templates) to the other resources (or returns links via HTTP Link headers)
a "poll collection" resource which provides for creation and access to individual polls (e.g. GET returns list of all polls, POST creates a new one)
individual polls, whose URIs are discovered though interactions with the "poll collection". GET, PUT, DELETE do as you might expect. I'm not sure if you'd need POST for these.
an "aggregation manager" resource that associates polls with aggregations (can a poll belong to more than one aggregation? - your description suggests not). A POST to this resource containing a POLL URI could locate-or-create an aggregation (or aggregations?) or create a new one. GET might return a list of existing aggregations.
individual aggregation resources whose URIs are discovered though interactions with the aggregation manager resource.
In your description, the PollPollAggregatorRel is part of your (current) implementation, not something you expose as such through the REST API. This gives you flexibility to change your internal implementation without affecting how clients use the API. That's the point of REST.
I'm not sure if you'd regard this as "easier and simpler", but that's not the point of REST. REST has been described by Roy Fielding as "software engineering on a scale of decades", and the point is to create an interface that allows relatively independent evolution of client and server implementations, which is crucial for an application that operates at web scale. There is a price to pay for this, which is that the client has to interact with the server to discover information it needs to progress an interaction.
Q2: I would not consider it sensible to mix REST and RPC in the same API. (It might make perfect sense to expose REST to external; clients and use RPC internally, or to offer separate APIs.)
My rationale for this is that if you have a mostly REST API, adding an RPC element potentially creates a tight coupling between client and server that rather negates the point of using REST in the first place.