Author Topic: Sharepoint and 5.9 Revisited  (Read 3510 times)

Offline Dean Wooldridge, Jr.

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 494
  • Karma: +9/-0
  • Gender: Male
    • View Profile
Sharepoint and 5.9 Revisited
« on: February 20, 2009, 10:17:22 AM »
OK so back on this Sharepoint and Pivotal conversation.† The single most hated thing from my user base is that they can open a document in Pivotal but they cannot write it back (easily) if they update it.† They have to save the thing locally, close, and then use Pivotal's upload to get it back into the database in updated form.† This is probably the strongest force driving users to SharePoint - ease of update.

I'm getting quite a few questions on how to make Pivotal and SharePoint work together when it comes to documents.† I've read through the existing material on this board and now I'm hoping that folks who have experimented with this will have more to say.† Someone commented about writing .NET code, someone referenced ODBC, someone else a comment on SharePoint Forms.† So if anyone has really accomplished something in this area I would love to hear about it especially if you can offer some real insight.† Some real-world "We did it like this and it sucked but when we did it this way it was great".

Offline PaulA

  • Full Member
  • ***
  • Posts: 35
  • Karma: +1/-0
    • View Profile
Re: Sharepoint and 5.9 Revisited
« Reply #1 on: February 22, 2009, 03:09:33 PM »
Yep have some real world experience using sharepoint to display and store documents related to an entity such as company.

Store the base URL for the share point web site in the system table and load it into a global variable using the on portal loaded event.

Use a form with a web segment to display sharepoint. In a .Net ASR fired on form load, use sharepoint web services to verify that the required sharepoint folder exists and if it doesn't create it and store the URL in a field on the form.

Pass the URL back to the form to populate the form web segment URL.

Pretty much it really. Works a treat. We used it for company related documents.

Be careful, if you create a lot of folders, as this breaks sharepoint, an undocumented feature. We were forced to group company alphabetically.


Offline CarlC

  • Hero Member
  • *****
  • Posts: 267
  • Karma: +28/-5
    • View Profile
Re: Sharepoint and 5.9 Revisited
« Reply #2 on: February 23, 2009, 03:55:49 AM »
Don't you dare take credit for that, Mr A ;)

Offline Dean Wooldridge, Jr.

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 494
  • Karma: +9/-0
  • Gender: Male
    • View Profile
Re: Sharepoint and 5.9 Revisited
« Reply #3 on: February 25, 2009, 02:55:21 PM »
So PaulA ---

Are you saying that the extent of what happened was to display a SharePoint URL in the web segment?  I bet your environment is similar to mine in that we have documents stored on contact, opportunity, company, etc. records.  We go to an opportunity we see only the related documents; we go to a contact we see only related documents; go to the company we see everything.  Were you able to address this?

What about other miscellaneous fields like comments, edit dates, and such?
What about security?

Is it a situation where you say "OK Pivotal, you have no real involvement in documents any longer other than to display the URL"?

Offline PaulA

  • Full Member
  • ***
  • Posts: 35
  • Karma: +1/-0
    • View Profile
Re: Sharepoint and 5.9 Revisited
« Reply #4 on: March 01, 2009, 06:21:26 AM »
Pretty much.

Let SharePoint do what is best at...document management, versioning and control. Use Pivotal to simplify the process of navigating to the correct folder (URL)  and if necessary create a new folder for the opportunity,contact, company etc.

If this is an IFD then security does become an issue, however the basic principles remains the same.

Offline Rommel

  • Full Member
  • ***
  • Posts: 35
  • Karma: +0/-0
  • Gender: Male
  • forza AC MILAN
    • View Profile
Re: Sharepoint and 5.9 Revisited
« Reply #5 on: September 25, 2009, 06:55:23 AM »

Dean,

Before you jump into using SharePoint,, I advice that you run some exercise on the potential growth of the number of folders on your company.

We had same solution implemented at our end, and unfortunately SharePoint has some limitations in querying huge volume of folders, also if you are talking to SharePoint via itís web services that will make it worse as web services are relatively slow.

So I imagine you will have a .NET wrapper that will have the proxy for SharePoint WS, and because of the nature of web services being slow and in case you have high volume of folders in SharePoint, that will eat from the PBS resources, which will definitely have a significant impact on performance.
 :o