What is the recommended way to introduce the invocation of an ASP.NET web service from a SharePoint list item event receiver (specifically, a MOSS 2007 document library)? I don't want to tightly couple the web service URL to the event receiver; but can I still add a service reference (or web reference) to the event receiver project, make the URL Behavior
dynamic, so I can update the reference's URL in the event receiver code using SharePoint's own web.config
or a feature property of the event receiver?
1 Answer
As you said, you could store the url of the service endpoint somewhere and then use that info from your event receiver. Two main options come to mind.
- Web.Config for the associated web application. By using the
SPWebConfigModification
class, either from a web application scoped feature or a PowerShell script you can apply modifications to the web.config file in a standard and automated way. SPWebConfigModification based changes are automatically propagated to all the servers in a farm, so they are the preferred way to handle changes in production environments. Just remember that SharePoint does not really like programmatically changes to be mixed with manual ones - so if you go for this road stick with it. Also, some customers do not really like to have changes applied to the web config from code developed by third parties/external companies. - Property Bags - many object in SharePoint have an associated property bag - think of it as a key-value store. The
SPFolder
is one of those objects, so an option is to save the url in the property bag associated to the root folder of the list you are using. Another option would be to use the web or site collection levels bags. This option is often preferred if the client don't want to risk having the web.config modified. This comes at a cost: there is no "UI" in SharePoint to change the value of a property bag key, or see which keys are defined, so you would need to build the interface to manage the settings on your own or do that directly via code.
As a related side note, I would also point out that unless you have some valid reason to do so, I wouldn't have the item receiver directly depending on a web service call, as it may require some time or even cause a timeout. If it is possible, I would try to move the core of the operation to some "batch" process. One idea could be using a SPLongOperation, but this would probably be worth another question by itself. Just ask yourself if you really need the item receiver to wait for the service call to complete
-
thanks for the insightful points and suggestions. That definitely helps.– Web UserDec 24, 2015 at 1:19
-
Your side note is very much in consideration because even I didn't feel comfortable with invoking a web service from the item receiver and introduce additional latency and another point of failure. On the slightly brighter side, the web service is invoked only once in the lifetime of the document added to the library and it does not happen every time the item is updated. Also, the lengthier part of the operations occur in the
itemUpdated
method which is inherentlyasynchronous
, so the user is not exposed to any delay. Still, there must be a better way...– Web UserDec 24, 2015 at 6:59