Can we test this with IOM somehow?  I would love to see what the interface looks like in a profile!

Hey Wayne, if you have a sandbox environment setup that would allow you hit a copy of your data (without the chance of hitting live data) we can make available a preview copy of IOM 3.0. IOM 3.0 uses a new framework for storing profiles and configuration information. As part of the process it will convert the profiles to that new structure and make them unable to be used by previous IOM versions. So just wouldn't want any chance of it converting your live profiles or anything.

Thanks
Shane

Cool, we are setting up a sandbox for 7.94 currently so I will let you know!

Sounds good! I should add that hopefully form an end user perspective you WON'T know a difference in the profile mapping. Ideally we're trying to keep the user experience as "classic" as possible. Obviously depending on your adapter and its data source it might require the end user to provide additional information, but otherwise the mapping field interface is run completely off of the metadata provided in the adapter. The "flat file" functionality that is core to IOM is actually using that entire adapter framework in IOM 3.0.

Yeah, my first foray into the data adapter was to just make something that would open up a CSV and read from it. Basically recreating the normal IOM functionality.

Perfect example, and we'd love to hear what everyone is able to come up with. We've worked on a several internally (e.g. support for XLS/XLSX, etc.) here but its nice to see what everyone else is doing.

The two I am going to be working on are connection to our web provider API (Blue State Digital) and Zendesk for donor support ticket information.

Another thing I was thinking is that the adapter could actually read from the RE Database to do cleanup processes. I could set up a stored procedure in the DB to find, for example, deceased records that are not "inactive" and then call that from the data adapter and run through the results to update them through IOM. A little meta and I'm not sure if there would be locking issues but it is something to think about!

Posted By Wayne Pozzar on 20 Feb 2015 02:54 PM
Another thing I was thinking is that the adapter could actually read from the RE Database to do cleanup processes. I could set up a stored procedure in the DB to find, for example, deceased records that are not "inactive" and then call that from the data adapter and run through the results to update them through IOM. 

I've thought about almost exactly the same thing. I was thinking a Constituent Query data adapter though...

Funnily enough (shut up, it's a word!) I just created a profile in IOM to run a query and email the results out. The "import file" is actually just a list of query names and email addresses and through the API I just run through the list, run the query, and then send the emails.

I am going to use it with the scheduler to set up a nightly task so that we can automate sending all kinds of queries like cleanup, gift/action notifications, even dashboards and updates to finance.

In a previous incarnation I built a profile that took in a query name, ran the query, output the results to a .csv, switched the ImportFile to point to the new .csv, and ran the import on that query result. It worked pretty well but I ended up using PHP for that kind of stuff since I wanted to pull straight from the DB with SQL.

Anyways, IOM is awesome!