I'm using sharepoint 2016 on prem. There are several solutions.
The solutions are deployed in a farm with 4wfe and 3backend server.
So collection uls can be very ugly and time consuming.
Instead I wanted to integrate application insight.
My first attempt was noch the best idea because I created every time an instance by myself and wrote s. Th. In to the instance and then forget it. There was no dispose method or s. Th.
So is it possible to integrate application insights in sharepoint as an elegant way?
Like a custom logging service or s. Th.?
Has anyone do it yet?
Related
i know this is gonna be a Little akward because the Image i am gonna post is in German,
but essentialy what i am trying to do, is create a Service Pool for Reporting Services,
now it is Very important that i am able to check the last Checkbox so my PowerPivot is gonna work, but i don't know what it is that's making it impossible for me to do so, anybody have any Ideas ?
NOTE: the message sais: There are no Webaplications associated with this SQL Server Reporting Services-Service Application available
Your Help is as always well Appreciated!
Fixed it, by removing the existing Association beetween the SSRS Service with the Web App,
apparently you can only associate one SSRS Service per Time
We have an ASP.NET website that we use internally to do some project tracking and various work. We would like to integrate some pieces of it to co-exist with Sharepoint2007 WSS.
Basically what we would really need to do is be able to add items to a list in one of the Sharepoint sites.
I'm not sure where to begin. I've looked online a bit but it seems overly complicated. Is there a quick start guide somewhere that can get me rolling with ease?
The SharePoint Web Services would be a logical place to start. In my opinion this would be the easiest way to build interaction between ASP.NET and SharePoint.
A list of available web services can be found on MSDN.
If adding items to a list is the primary goal, then check out the UpdateListItems method of the Lists web service.
With the scope narrowed to Web Services, you can certainly find tutorials/references online. However, this InfoQ post by Trent Swanson is a decent introduction to SP web services. Note that they recommend generating .NET types using XSD files; in practice, for simple projects I have simply parsed the XML myself using LINQ. You can make it as easy or complex as you like, I suppose.
We currently have a fully developed web forms application, basically its like WordPress using .net for multiple users to publish content. It does more than that but thats the simplest way to describe it. Our "webmasters" (I work in the gov) want everything put inside of SharePoint. We currently have SharePoint 2007. I have no experience developing within SharePoint so I don't know much about it.
My question is how do you decide when to develop your application in SharePoint and when to develop outside of it.
It depends on several things.
Is there any reason to use SharePoint features (lists for data storage, document libraries with versioning, groups for security, etc.) in your application? If you're just hosting ASP.NET pages within SharePoint but aren't using any of its features, it's not really worth the hassle.
However, if you would be adding the application to an existing SharePoint site, it might still be a good idea. Organizing everything in one place might be more convenient for users than setting up a separate web application.
If it is a requirement to re-architect your application to work with SharePoint, that is one very big reason to develop with SharePoint. Beyond that, the people influencing your architecture decisions may have good reasons of their own.
SharePoint provides security management, search and navigation to name a few relevant pieces to your web puzzle. If you are already creating dynamic web applications in .Net, a lot of what you've learned in the process will apply, but you have some learning to do.
Your orginization is not the only one moving most web applications to SharePoint. If you don't learn it now, you risk getting behind the curve.
You could also just 'show' your existing applications inside of a SharePoint web part (Page Viewer?). That way, your application remains the same, and it is 'shown' inside the SharePoint environment. This is somewhat a hokey solution, but in your particular circumstance, it could be viable considering development time, learning time, and control.
We are currently in the process of drawing up a solution for an existing client, creating a number of eServices. The client currently have MOSS 2007. The proposed solution is to use MOSS as the launching pad for the eServices…
The requirement involves drawing up several online forms which provide registration facilities as well as facilitating a workflow of some sort. I have been told that the proposed solution requires complex web forms.
Most are complex forms with parent child details that have multiple windows. The proposed solution is to do some bespoke development, developing ASP .NET forms. These forms would be deployed under the _layouts folder of the current MOSS portal, inheriting the master page design on the current site.
I have been told that this approach make development and deployment more simple, as well has having ‘complete integration’ with MOSS.
My questions are:
Is this the best way to leverage SharePoint – it seems like the proposed solution is not leveraging MOSS at all..! I thought perhaps utilizing Web Parts would be better, but I have been told that this is more complex and developing more smarter intuitive UI is more difficult. Is this really the case? If not, what should be the recommended approach?
We will be utilizing Ultimus as the workflow engine. However, I have been recommended K2 Workflows. Anyone used both/have any opinions on either?
Many thanks in advance!
Kind Regards,
If they have MOSS 2007 Enterprise, you might consider if web rendered InfoPath forms can meet your needs for "complex web forms". When it comes down to it, probably all of these technologies can meet the neeed it is just a matter of what skill sets you and your customer have and how that will facilitate keeping this solution up to date.
Asim, what they propose is a possible solution. They can however provide the same functionality by making use of webparts. With the details you are giving us that isn't really possible to decide which option would be easier. I used both approaches in the same project depending on the requirements of each functionality.
I can understand that it doesn't seem like they are leveraging MOSS, but they actually are building pages within the context of MOSS.
I haven't really heard about Ultimus, I did use K2 in a proof of concept and I was quite happy with it. Then again, choosing the right workflow solution depends on your requirements.
I'm trying to create/add a Sharepoint subsite on an existing site collection through the web service api (as oppposed to the object model or RPC), but I see no clear way on any of the Admin.asmx, Webs.asmx, Site.asmx, or Sites.asmx services to do so.
I can see ways to create a full site collection, lists, and list items, but not to create a subsite on an existing site collection.
Can someone please confirm whether or not there is a way on the out-of-the-box sharepoint web services to do this?
It's exceedingly (well, maybe not exceedingly) easy to create your own SharePoint-aware web service. If the existing API isn't sufficient to meet your needs, then you might consider rolling your own to give you more domain-specific functionality. I found this MSDN article to be pretty helpful, and I rolled up the WSDL modifications into a post-build event to simplify the edit-build-deploy process.
http://msdn.microsoft.com/en-us/library/ms464040.aspx
I have googled around and found these 2 references
http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/47d63dbf-3740-4e97-bc5c-17c39ef7b174/
http://community.officesharepointpro.com/forums/post/16971.aspx