You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Chad Cross <ch...@gmail.com> on 2011/04/15 14:58:22 UTC
A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
All,
I'm in the middle of what could be a very interesting opportunity for my
company and I'm in need of assistance.
Our accounting system, Microsoft Dynamics SL, is central to everything we
do. Right now we have a need for a mobile app that interacts with a very
small subset of data stored in this system. Currently, others in my tiny IT
department are pushing hard and evaluating a solution that involves
SharePoint 2010 (which we already own) for hosting, InfoPath for form
creation, and 3rd party wrappers that allow the "application" to be accessed
via Android, Windows Mobile 6.5, and iOS. Those wrappers include Mobile
Entree <http://www.mobileentree.com/>,
SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
and others that they discover every day.
Their biggest concern is concurrency. The idea that a service technician
could be in the field and interacting with the software to pull down
information about a specific trouble ticket, walk into an area without
coverage, and still be able to input data. When they return to coverage,
the app should handle pushing that data back to the database without
encountering concurrency issues.
I'm sure some of you have experience battling suits when it comes to
proposing alternative solutions (and in my case, "alternative" means
non-Microsoft), so I would like for anyone that has experience with CouchDB
and MS-SQL interaction to please chime in!
Thanks!
-Chad
P.S. For you Twitter users, please retweet!
https://twitter.com/#!/TheChadCross/status/58871610505039872
Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Posted by Chad Cross <ch...@gmail.com>.
Phil,
THANK YOU for the extremely valuable input.
When I'm speaking of avoiding .NET/SharePoint, it's only because I feel like
I've been beaten over the head with it. I believe in the right tool for the
job and I've been fed a constant line of "there is only one tool (.NET) for
every job".
No one on our team has experience developing web applications like the one
I've described, so if we have to learn how to do something in the first
place, let's learn something that will be valuable to us all in the long
run.
The point you're making about limiting data collisions from the onset is
extremely valuable and I appreciate you sharing that.
-Chad
On Mon, Apr 18, 2011 at 10:28 AM, Phil Stanhope <st...@gmail.com> wrote:
> I'd avoid getting stuck in the .NET is bad thinking. SharePoint and
> Dynamics
> both have very rich WS-* compliant APIs in front of their data tier.
>
> Having built apps that do exactly what the user scenarios are I think it's
> best to think through a couple of points about data and potential for
> concurrent updates.
>
> 1. The technician scenario inherently avoid many concurrency problems
> because each technician ONLY gets their tickets. They have access to nobody
> else's -- they are on a spoke.
>
> 2. The manager of the technicians has a view to all tickets and time a
> ticket is opened. Some sort of data crumb needs to be left at time of
> ticket
> "checkout" such that a conflict can be dealt with if, upon return (e.g.
> technician got in a car accident and another technician was dispatched),
> that any attempt to update the ticket is denied and manual reconcilation
> can
> occur.
>
> 3. Because the backend stack has all sorts of HTTP(S) accessible web
> services ... the client can be completely agnostic as to backend data store
> and backend (SharePoint/Dynamics) presentation of the data form the hub's
> perspective.
>
> 4. CouchDB can solve a significant part of the problem if it's used as the
> temporary activity store. Data is copied out from SharePoint/Dynamics into
> a
> master CouchDB database. Then Couch's ability to replicate shards (specific
> technician's data) is used. Couch is used to manage conflicts on document
> updates. Document update hooks at the hub are then used to push completed
> tickets back into the main data depots.
>
> The more that you can construct the dataflows such that it's truely hub and
> spoke with human behavior enforcing the data update cycles ... the less
> likely that any conflicts will ever occur in the first place.
>
> This model has been proven time and time again against Lotus Notes and
> similar partial replica synchronized systems for the past 25+ years.
>
> The system can never be ACID ... but so what. Decrease the likelihood of
> conflict in the first place ... and put the conflict resolution of the
> hands
> of the few people who can resolve the conflict by manual intervention at
> the
> point in time that it happens / is discovered.
>
>
> On Mon, Apr 18, 2011 at 9:30 AM, Jason Lane <jasonlanexml@googlemail.com
> >wrote:
>
> > On 18 April 2011 13:53, Chad Cross <ch...@gmail.com> wrote:
> >
> > > It's encouraging that you were able to propose that sort of solution at
> > > such
> > > a company.
> > >
> > > I have a surprise meeting in 4 hours to discuss "solutions". I think
> > this
> > > may be an admittance that SharePoint is not the right solution for what
> > we
> > > want, but unfortunately I don't have much of anything to show in such a
> > > short period of time.
> > >
> > > Here is the basic usage scenario:
> > >
> > > 1. Technican approaches downloads building information/ticket
> > information
> > > to his/her mobile for a service request.
> > > 2. Technican enters building and no longer has connectivity to the
> > remote
> > > server
> > > 3. Technican enters data on their mobile about the work they've
> > completed
> > > (assuming this is HTML/JS based, the local data store could be used
> to
> > > temporarily store this data?)
> > >
> >
> > Absolutely. This is another are I have worked on. especially if the
> devices
> > are iOS / Android HTML5 is a given
> >
> >
> > > 4. Technican returns to coverage area and needs to send their data
> back
> > > to the remote server (by all accounts we have to create our own
> > conflict
> > > resolution system if the records the Technican wishes to update have
> > been
> > > updated while they were out of coverage)
> > >
> > > I'm sure this is small potatoes for the community at large to explain
> to
> > > one
> > > another, but what's the proper way to discuss this with peers/superiors
> > > that
> > > are completely stuck in a .NET mindset?
> > >
> >
> > Technological debt!
> >
> >
> > >
> > > Thanks everyone!
> > >
> > > -Chad
> > >
> > > On Fri, Apr 15, 2011 at 3:08 PM, Jason Lane <
> jasonlanexml@googlemail.com
> > > >wrote:
> > >
> > > > Why don't you look at non-blocking architecture throughout the stack.
> > I'd
> > > > recommend looking at Couchdb & Nodejs. I gave a presentation at work
> > > > recently on concurrent, non-blocking, event based architectures at my
> > > work.
> > > > I work for Thomsonreuters, big lumbering corporation that it is.
> > > >
> > > > sent from my Nexus S
> > > > On Apr 15, 2011 1:58 PM, "Chad Cross" <ch...@gmail.com> wrote:
> > > > > All,
> > > > >
> > > > > I'm in the middle of what could be a very interesting opportunity
> for
> > > my
> > > > > company and I'm in need of assistance.
> > > > >
> > > > > Our accounting system, Microsoft Dynamics SL, is central to
> > everything
> > > we
> > > > > do. Right now we have a need for a mobile app that interacts with a
> > > very
> > > > > small subset of data stored in this system. Currently, others in my
> > > tiny
> > > > IT
> > > > > department are pushing hard and evaluating a solution that involves
> > > > > SharePoint 2010 (which we already own) for hosting, InfoPath for
> form
> > > > > creation, and 3rd party wrappers that allow the "application" to be
> > > > accessed
> > > > > via Android, Windows Mobile 6.5, and iOS. Those wrappers include
> > Mobile
> > > > > Entree <http://www.mobileentree.com/>,
> > > > > SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> > > > > and others that they discover every day.
> > > > >
> > > > > Their biggest concern is concurrency. The idea that a service
> > > technician
> > > > > could be in the field and interacting with the software to pull
> down
> > > > > information about a specific trouble ticket, walk into an area
> > without
> > > > > coverage, and still be able to input data. When they return to
> > > coverage,
> > > > > the app should handle pushing that data back to the database
> without
> > > > > encountering concurrency issues.
> > > > >
> > > > > I'm sure some of you have experience battling suits when it comes
> to
> > > > > proposing alternative solutions (and in my case, "alternative"
> means
> > > > > non-Microsoft), so I would like for anyone that has experience with
> > > > CouchDB
> > > > > and MS-SQL interaction to please chime in!
> > > > >
> > > > > Thanks!
> > > > >
> > > > > -Chad
> > > > >
> > > > > P.S. For you Twitter users, please retweet!
> > > > > https://twitter.com/#!/TheChadCross/status/58871610505039872
> > > >
> > >
> >
>
Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Posted by Phil Stanhope <st...@gmail.com>.
I'd avoid getting stuck in the .NET is bad thinking. SharePoint and Dynamics
both have very rich WS-* compliant APIs in front of their data tier.
Having built apps that do exactly what the user scenarios are I think it's
best to think through a couple of points about data and potential for
concurrent updates.
1. The technician scenario inherently avoid many concurrency problems
because each technician ONLY gets their tickets. They have access to nobody
else's -- they are on a spoke.
2. The manager of the technicians has a view to all tickets and time a
ticket is opened. Some sort of data crumb needs to be left at time of ticket
"checkout" such that a conflict can be dealt with if, upon return (e.g.
technician got in a car accident and another technician was dispatched),
that any attempt to update the ticket is denied and manual reconcilation can
occur.
3. Because the backend stack has all sorts of HTTP(S) accessible web
services ... the client can be completely agnostic as to backend data store
and backend (SharePoint/Dynamics) presentation of the data form the hub's
perspective.
4. CouchDB can solve a significant part of the problem if it's used as the
temporary activity store. Data is copied out from SharePoint/Dynamics into a
master CouchDB database. Then Couch's ability to replicate shards (specific
technician's data) is used. Couch is used to manage conflicts on document
updates. Document update hooks at the hub are then used to push completed
tickets back into the main data depots.
The more that you can construct the dataflows such that it's truely hub and
spoke with human behavior enforcing the data update cycles ... the less
likely that any conflicts will ever occur in the first place.
This model has been proven time and time again against Lotus Notes and
similar partial replica synchronized systems for the past 25+ years.
The system can never be ACID ... but so what. Decrease the likelihood of
conflict in the first place ... and put the conflict resolution of the hands
of the few people who can resolve the conflict by manual intervention at the
point in time that it happens / is discovered.
On Mon, Apr 18, 2011 at 9:30 AM, Jason Lane <ja...@googlemail.com>wrote:
> On 18 April 2011 13:53, Chad Cross <ch...@gmail.com> wrote:
>
> > It's encouraging that you were able to propose that sort of solution at
> > such
> > a company.
> >
> > I have a surprise meeting in 4 hours to discuss "solutions". I think
> this
> > may be an admittance that SharePoint is not the right solution for what
> we
> > want, but unfortunately I don't have much of anything to show in such a
> > short period of time.
> >
> > Here is the basic usage scenario:
> >
> > 1. Technican approaches downloads building information/ticket
> information
> > to his/her mobile for a service request.
> > 2. Technican enters building and no longer has connectivity to the
> remote
> > server
> > 3. Technican enters data on their mobile about the work they've
> completed
> > (assuming this is HTML/JS based, the local data store could be used to
> > temporarily store this data?)
> >
>
> Absolutely. This is another are I have worked on. especially if the devices
> are iOS / Android HTML5 is a given
>
>
> > 4. Technican returns to coverage area and needs to send their data back
> > to the remote server (by all accounts we have to create our own
> conflict
> > resolution system if the records the Technican wishes to update have
> been
> > updated while they were out of coverage)
> >
> > I'm sure this is small potatoes for the community at large to explain to
> > one
> > another, but what's the proper way to discuss this with peers/superiors
> > that
> > are completely stuck in a .NET mindset?
> >
>
> Technological debt!
>
>
> >
> > Thanks everyone!
> >
> > -Chad
> >
> > On Fri, Apr 15, 2011 at 3:08 PM, Jason Lane <jasonlanexml@googlemail.com
> > >wrote:
> >
> > > Why don't you look at non-blocking architecture throughout the stack.
> I'd
> > > recommend looking at Couchdb & Nodejs. I gave a presentation at work
> > > recently on concurrent, non-blocking, event based architectures at my
> > work.
> > > I work for Thomsonreuters, big lumbering corporation that it is.
> > >
> > > sent from my Nexus S
> > > On Apr 15, 2011 1:58 PM, "Chad Cross" <ch...@gmail.com> wrote:
> > > > All,
> > > >
> > > > I'm in the middle of what could be a very interesting opportunity for
> > my
> > > > company and I'm in need of assistance.
> > > >
> > > > Our accounting system, Microsoft Dynamics SL, is central to
> everything
> > we
> > > > do. Right now we have a need for a mobile app that interacts with a
> > very
> > > > small subset of data stored in this system. Currently, others in my
> > tiny
> > > IT
> > > > department are pushing hard and evaluating a solution that involves
> > > > SharePoint 2010 (which we already own) for hosting, InfoPath for form
> > > > creation, and 3rd party wrappers that allow the "application" to be
> > > accessed
> > > > via Android, Windows Mobile 6.5, and iOS. Those wrappers include
> Mobile
> > > > Entree <http://www.mobileentree.com/>,
> > > > SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> > > > and others that they discover every day.
> > > >
> > > > Their biggest concern is concurrency. The idea that a service
> > technician
> > > > could be in the field and interacting with the software to pull down
> > > > information about a specific trouble ticket, walk into an area
> without
> > > > coverage, and still be able to input data. When they return to
> > coverage,
> > > > the app should handle pushing that data back to the database without
> > > > encountering concurrency issues.
> > > >
> > > > I'm sure some of you have experience battling suits when it comes to
> > > > proposing alternative solutions (and in my case, "alternative" means
> > > > non-Microsoft), so I would like for anyone that has experience with
> > > CouchDB
> > > > and MS-SQL interaction to please chime in!
> > > >
> > > > Thanks!
> > > >
> > > > -Chad
> > > >
> > > > P.S. For you Twitter users, please retweet!
> > > > https://twitter.com/#!/TheChadCross/status/58871610505039872
> > >
> >
>
Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Posted by Jason Lane <ja...@googlemail.com>.
On 18 April 2011 13:53, Chad Cross <ch...@gmail.com> wrote:
> It's encouraging that you were able to propose that sort of solution at
> such
> a company.
>
> I have a surprise meeting in 4 hours to discuss "solutions". I think this
> may be an admittance that SharePoint is not the right solution for what we
> want, but unfortunately I don't have much of anything to show in such a
> short period of time.
>
> Here is the basic usage scenario:
>
> 1. Technican approaches downloads building information/ticket information
> to his/her mobile for a service request.
> 2. Technican enters building and no longer has connectivity to the remote
> server
> 3. Technican enters data on their mobile about the work they've completed
> (assuming this is HTML/JS based, the local data store could be used to
> temporarily store this data?)
>
Absolutely. This is another are I have worked on. especially if the devices
are iOS / Android HTML5 is a given
> 4. Technican returns to coverage area and needs to send their data back
> to the remote server (by all accounts we have to create our own conflict
> resolution system if the records the Technican wishes to update have been
> updated while they were out of coverage)
>
> I'm sure this is small potatoes for the community at large to explain to
> one
> another, but what's the proper way to discuss this with peers/superiors
> that
> are completely stuck in a .NET mindset?
>
Technological debt!
>
> Thanks everyone!
>
> -Chad
>
> On Fri, Apr 15, 2011 at 3:08 PM, Jason Lane <jasonlanexml@googlemail.com
> >wrote:
>
> > Why don't you look at non-blocking architecture throughout the stack. I'd
> > recommend looking at Couchdb & Nodejs. I gave a presentation at work
> > recently on concurrent, non-blocking, event based architectures at my
> work.
> > I work for Thomsonreuters, big lumbering corporation that it is.
> >
> > sent from my Nexus S
> > On Apr 15, 2011 1:58 PM, "Chad Cross" <ch...@gmail.com> wrote:
> > > All,
> > >
> > > I'm in the middle of what could be a very interesting opportunity for
> my
> > > company and I'm in need of assistance.
> > >
> > > Our accounting system, Microsoft Dynamics SL, is central to everything
> we
> > > do. Right now we have a need for a mobile app that interacts with a
> very
> > > small subset of data stored in this system. Currently, others in my
> tiny
> > IT
> > > department are pushing hard and evaluating a solution that involves
> > > SharePoint 2010 (which we already own) for hosting, InfoPath for form
> > > creation, and 3rd party wrappers that allow the "application" to be
> > accessed
> > > via Android, Windows Mobile 6.5, and iOS. Those wrappers include Mobile
> > > Entree <http://www.mobileentree.com/>,
> > > SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> > > and others that they discover every day.
> > >
> > > Their biggest concern is concurrency. The idea that a service
> technician
> > > could be in the field and interacting with the software to pull down
> > > information about a specific trouble ticket, walk into an area without
> > > coverage, and still be able to input data. When they return to
> coverage,
> > > the app should handle pushing that data back to the database without
> > > encountering concurrency issues.
> > >
> > > I'm sure some of you have experience battling suits when it comes to
> > > proposing alternative solutions (and in my case, "alternative" means
> > > non-Microsoft), so I would like for anyone that has experience with
> > CouchDB
> > > and MS-SQL interaction to please chime in!
> > >
> > > Thanks!
> > >
> > > -Chad
> > >
> > > P.S. For you Twitter users, please retweet!
> > > https://twitter.com/#!/TheChadCross/status/58871610505039872
> >
>
Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development
Stack
Posted by Owen Marshall <om...@facilityone.com>.
On 04/18/2011 08:53 AM, Chad Cross wrote:
> Here is the basic usage scenario:
>
> 1. Technican approaches downloads building information/ticket information
> to his/her mobile for a service request.
> 2. Technican enters building and no longer has connectivity to the remote
> server
> 3. Technican enters data on their mobile about the work they've completed
> (assuming this is HTML/JS based, the local data store could be used to
> temporarily store this data?)
> 4. Technican returns to coverage area and needs to send their data back
> to the remote server (by all accounts we have to create our own conflict
> resolution system if the records the Technican wishes to update have been
> updated while they were out of coverage)
In this case, one/more technician(s) will pull down one/more ticket(s),
work them offline, and push them back up to the centralized server.
But in most workflows, that's not the end of it: most times, a manager
will have to review and sign off on each ticket, or at least acknowledge it.
Resolve your conflicts at the management level. If the manager needs to
check the "Approved" box, and two techs report that they both did a
ticket, the manager will have the knowledge to handle the discrepancy.
A few other places where CouchDB will likely fit well:
* Native HTTP API makes sending data from their mobile to the server
stupid easy. This API will also make getting data into your .NET
application stupid easy.
IMO, this is the biggest win. With CouchDB you can just capture the JSON
in the mobile's LocalStorage, and then send the JSON straight to
CouchDB. Done!
* If HTML5 LocalStorage doesn't fit the bill (it likely will), CouchDB
can run natively on iPhone/Android -- see couchbase.com &
https://github.com/couchbaselabs
--
Owen Marshall
FacilityONE
omarshall@facilityone.com | (502) 805-2126
Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Posted by Chad Cross <ch...@gmail.com>.
It's encouraging that you were able to propose that sort of solution at such
a company.
I have a surprise meeting in 4 hours to discuss "solutions". I think this
may be an admittance that SharePoint is not the right solution for what we
want, but unfortunately I don't have much of anything to show in such a
short period of time.
Here is the basic usage scenario:
1. Technican approaches downloads building information/ticket information
to his/her mobile for a service request.
2. Technican enters building and no longer has connectivity to the remote
server
3. Technican enters data on their mobile about the work they've completed
(assuming this is HTML/JS based, the local data store could be used to
temporarily store this data?)
4. Technican returns to coverage area and needs to send their data back
to the remote server (by all accounts we have to create our own conflict
resolution system if the records the Technican wishes to update have been
updated while they were out of coverage)
I'm sure this is small potatoes for the community at large to explain to one
another, but what's the proper way to discuss this with peers/superiors that
are completely stuck in a .NET mindset?
Thanks everyone!
-Chad
On Fri, Apr 15, 2011 at 3:08 PM, Jason Lane <ja...@googlemail.com>wrote:
> Why don't you look at non-blocking architecture throughout the stack. I'd
> recommend looking at Couchdb & Nodejs. I gave a presentation at work
> recently on concurrent, non-blocking, event based architectures at my work.
> I work for Thomsonreuters, big lumbering corporation that it is.
>
> sent from my Nexus S
> On Apr 15, 2011 1:58 PM, "Chad Cross" <ch...@gmail.com> wrote:
> > All,
> >
> > I'm in the middle of what could be a very interesting opportunity for my
> > company and I'm in need of assistance.
> >
> > Our accounting system, Microsoft Dynamics SL, is central to everything we
> > do. Right now we have a need for a mobile app that interacts with a very
> > small subset of data stored in this system. Currently, others in my tiny
> IT
> > department are pushing hard and evaluating a solution that involves
> > SharePoint 2010 (which we already own) for hosting, InfoPath for form
> > creation, and 3rd party wrappers that allow the "application" to be
> accessed
> > via Android, Windows Mobile 6.5, and iOS. Those wrappers include Mobile
> > Entree <http://www.mobileentree.com/>,
> > SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> > and others that they discover every day.
> >
> > Their biggest concern is concurrency. The idea that a service technician
> > could be in the field and interacting with the software to pull down
> > information about a specific trouble ticket, walk into an area without
> > coverage, and still be able to input data. When they return to coverage,
> > the app should handle pushing that data back to the database without
> > encountering concurrency issues.
> >
> > I'm sure some of you have experience battling suits when it comes to
> > proposing alternative solutions (and in my case, "alternative" means
> > non-Microsoft), so I would like for anyone that has experience with
> CouchDB
> > and MS-SQL interaction to please chime in!
> >
> > Thanks!
> >
> > -Chad
> >
> > P.S. For you Twitter users, please retweet!
> > https://twitter.com/#!/TheChadCross/status/58871610505039872
>
Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Posted by Jason Lane <ja...@googlemail.com>.
Why don't you look at non-blocking architecture throughout the stack. I'd
recommend looking at Couchdb & Nodejs. I gave a presentation at work
recently on concurrent, non-blocking, event based architectures at my work.
I work for Thomsonreuters, big lumbering corporation that it is.
sent from my Nexus S
On Apr 15, 2011 1:58 PM, "Chad Cross" <ch...@gmail.com> wrote:
> All,
>
> I'm in the middle of what could be a very interesting opportunity for my
> company and I'm in need of assistance.
>
> Our accounting system, Microsoft Dynamics SL, is central to everything we
> do. Right now we have a need for a mobile app that interacts with a very
> small subset of data stored in this system. Currently, others in my tiny
IT
> department are pushing hard and evaluating a solution that involves
> SharePoint 2010 (which we already own) for hosting, InfoPath for form
> creation, and 3rd party wrappers that allow the "application" to be
accessed
> via Android, Windows Mobile 6.5, and iOS. Those wrappers include Mobile
> Entree <http://www.mobileentree.com/>,
> SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> and others that they discover every day.
>
> Their biggest concern is concurrency. The idea that a service technician
> could be in the field and interacting with the software to pull down
> information about a specific trouble ticket, walk into an area without
> coverage, and still be able to input data. When they return to coverage,
> the app should handle pushing that data back to the database without
> encountering concurrency issues.
>
> I'm sure some of you have experience battling suits when it comes to
> proposing alternative solutions (and in my case, "alternative" means
> non-Microsoft), so I would like for anyone that has experience with
CouchDB
> and MS-SQL interaction to please chime in!
>
> Thanks!
>
> -Chad
>
> P.S. For you Twitter users, please retweet!
> https://twitter.com/#!/TheChadCross/status/58871610505039872