A few days ago I gave in to a bit of discouragement and posted a long diatribe on why I am afraid the story for Office 365 and Access web apps is discouraging.
Well, it turns out I was premature in my efforts at digging a grave for my BFF, Access. What a relief.
Here are the three big reasons I was so pessimistic, and the reasons I now have a lot more reasonable view. Again, keep in mind that this is entirely based on my work with the Preview on Office 365 and has nothing at all to do with on-premises SharePoint installations.
1) The data siloing and sealing scenario is not as much of a dead-end as it is a hurdle that can be crossed, if we just have patience.
2) There really is a life-cycle story for these apps. It's not as pretty and neat as we might like, but it is a true story.
3) Inter user credentialing can be finessed, with enough imagination and patience.
Again, out-of-the-box, I'm pretty sure the typical "Johnny Poweruser" is not going to do much more than build himself a tool to track packages shipped out by his department, or maybe host a department site for time off requests, or something similar. Nothing high-level, nothing too complex.
But, there does seem to be a story to tell about extending these web apps. Moreover, as I see it, that story has to include developers after all.
1) Right now, of course, the path for data in Access web apps on O365 is still one-way. And that's not good. When the pathway is opened for data flow in the other direction, though, the biggest pain point gets a lot smaller. In an on-premises environment, a user can connect to their SQL Azure, or SQL Server, database from SSMS and work directly with the data in their Access web apps . When that same feature is opened up to Office 365, we will be able to at least create a backup of the data, or get to it for local use.
2) It turns out the app life-cycle story is not all that different, conceptually, from what we've always done with Access mdbs and accdbs: Make a local copy of the app (with or without data) and restore it, if necessary, to a production environment. The tools and techniques are still a bit raw, shall we say, and not really fit for Johnny's use. But it's there, and it's actually documented on MSDN! The url is http://msdn.microsoft.com/en-us/library/fp179918(v=office.15).aspx
3) Inter user credentialing does seem to have a solution, although I am afraid it's going to be "roll-your-own" in large part. We have three expressions that retrieve information about the currently logged on user. These are:
UserLoginName()
UserDisplayName()
UserEmailAddress()
It seems to me that a combination of these expressions and data macros should allow us to figure out a way to control access to data. I've not worked it out yet, and I'm not 100% sure how it's going to work. But there does seems to be a path there.
So, after a few days of rest, and a thoughtful discussion with some of my friends and colleagues, I guess I can recover a bit from my pessimistic outlook of a few days back.
I'll be following up again soon, as I begin to implement some of these concepts in my test apps.
