Scenario: We have four databases that are setup to inherit from a master template and they in turn have individual design elements that inherit from a different master template via template name added in the field shown in image.
It has always been my understanding that in order for the individual design elements in the database to inherit any changes a version of the master template must also be on all servers where the database resides so that the nightly server process will make updates to the design element(s).
Is this true? Does this change when creating a build using Teamstudio CIAO Builds/Promotions?
If you want changes to any design elements to be automatically picked up from templates overnight - regardless of whether they inherit individually as in your screenshot, or inherit from the template named in the database properties - then one of the following must be true:
If the database is replicated to multiple servers, then the templates must be on at least one of those servers; or
If the database is only on one server, then the templates must be on that server.
So, if you have a few databases that are on one server each and not replicated, and they inherit from the same templates, then you'd need those templates on every server to get automatic overnight inheritance in every database.
However, there's no need to rely on automatic inheritance, as users with Designer access to affected databases can manually refresh designs from templates using the Notes or Designer client. If you do this, you can keep the templates on just one server regardless of how many servers have databases using those templates.
Note regarding template designs in any case, whether databases are automatically or manually refreshed: Best practice (as I understand it) is to have production template designs signed by a single user id created for the express purpose of signing designs, with a Domino policy in place to ensure that all users Execution Control Lists (ECLs) trust that signer, to prevent users from getting ECL alerts when using production applications.
My experience with Teamstudio CIAO isn't extensive, but I don't think it changes any of the above.
CIAO! / Build Manager uses the IBM Domino API to perform a Design Refresh, therefore it does not need to wait for the nightly Design task to run.
CIAO! / Build Manager calls the Design Refresh API and passes the Target DB info and then name of the IBM Server where the template resides. Therefore for a full design refresh of a Target db the Template does not need to reside on the same server.
If you have indicated a Design Template for individual Design Elements within a Notes Application, then in this scenario the Master Template would need to reside on the IBM Domino server where the Notes Application also resides. The CIAO! / Build Manager application does not include the capability of updating these individual Design Elements.
Related
I am authoring an installer that creates a new website and application pool. This installer is for internal use within several development environments which all have subtle differences. One may use only HTTP, another only HTTPS and one might use both. One might use the default ApplicationPoolIdentity identity where as another may use an explicit User reference.
Given the association of a WebAppPool is by ID through a WebApplication which must be nested under a WebSite, each time an option is desired on the installer, the breakout and duplication of features gets ridiculous.
I imagine I am not the first to encounter this, how does one accomplish this much flexibility within an installer?
The route I went with was creating a basic template within WIX using expected IDs, then used an immediate custom action scheduled before InstallValidate which manipulated the template entries to what ever degree was required. The properties used by the CA to make the decisions are stored in the registry for modify/patch/removal invocations.
I don't know about SharePoint that much, so hope that someone can give me some good explanations for me.
For SharePoint application, we don't need to consider SharePoint DB design? Everything is done through List and SharePoint will take care of the Database? Don't need to consider it at all unless we are connecting to the external Database?
For Parent Child relationship, I have to use lookup field?
If we are developing using Web parts, we need to deploy it using Features. So eventually, there can be so many features in the production? Is it recommended in this way?
1)
For SharePoint application, we don't need to consider SharePoint DB
design ? Everything is done through List and SharePoint will take care
of the Database ? Don't need to consider it at all unless we are
connecting to the external Database ?
You do need to consider the database... In term of administration. back ups, restore, size and so on.
however you never directly read or write to it. You don't need to pay attention to the schema because you won't ever be directly using it. If you want to update something in SharePoint you do it pragmatically with c# / vb.net using the SharePoint API's. You have 2 API's one that works on the server called the SharePoint object model and one that works on a remote machine called the client side object model.
From a users perspective, you are correct lists contain data in SharePoint and are somewhat smiler to DB tables in some ways.
2)
For Parent Child relationship, I have to use lookup field ?
Yip
3)
If we are developing using Web parts, we need to deploy it using
Features. So eventually, there can be so many features in the
production ? Is it recommended in this way?
This can happen if you create a new solution for every web part but you can bundle multiple web parts in the same solution in the same project in the same feature
Right click on your project --> add new item. select a web part. By default the web parts will all be part of the same feature but you can separate them out and have multiple features in the same solution if you want to
We have a legacy Lotus Notes application that we want to see if we can make an improvement, first by making a test environment for this application. Currently the application is located on the main server and being replicated every 15 minutes to the web server. The replica on the web server has different forms and views since they are adjusted to display the information on the web browser (in my understanding)
I have made a new copy of the application that is on the main server without any problem. I had some problem replicating it to the web server since I do not understand what will happen to those element design that are not being used in the application on the web server. So what I did was replicating the application from the main server to the web server, then deleted all the design elements on the web test then copy all the design elements from the production environment to the web test.
By doing that I was able to get into the login page then log in. After I login, the frameset that suppose to display the default view giving this error message 'HTTP Web Server: Couldn't find design note'. First of all, I thought this is normal since I could not find the view in the database and that confused me since the live system works without that view present on the database BUT when I tried to access a view that I know present on the database, I still get the same error.
So after all that I opened the web test application on a Lotus Notes client. I can open the views that are exist. Now at this point there are 2 things that I am very frustrated about:
The live system works even when the code specifically mentions views that I cannot find from the Domino Designer. It just does not make any sense
As a test I created a 'Test' view on the web test application. Basically I just told it to fetch one of the form called 'WORec' that contains Work Order information. Into my surprise, the view opens up on the web browser but shows no result, which frustrates me even more since the view 'WOByName' gets all the Work Orders just fine. These 2 views have the same selection formula, so I really do not understand why 1 view is able to show data where the other does not. Moreover if I tell the test view to fetch all the documents in the database it only fetch those documents that are not 'WORec' form
I know this is long but if I can get some pointers on what I am doing wrong here. I am just trying to create a test environment. Unfortunately I never dealt with Domino web application or a replication that completely has different element design.
Let's start with the test view.
When you created the view, you need to first verify it is a Public view. Private views or Shared Private on First Use (SPOFU) views are not what you want here.
also, verify the name and alias of the view is unique to your database.
Next, verify your selection formula is correct.
use formula, instead of simple so you can actually see the formula. e.g.
SELECT #UpperCase(Form) = "WOREC"
Refresh your view designer (F9) - do you see your records coming through?
also, make sure the view is not hidden from Web clients... you will see this in the designer client, when looking at a list of views - a column indicating whether or not it is hidden from web clients, note clients, mobile clients, etc.
if not, open one of the documents up. Show properties, verify the form property in the box (2nd tab), matches the value "WORec". If not, correct your view selection with the correct form name spelling.
Next, you need to make sure you are allowed to view this from the web.
Open the Access Control List (ACL) and add "anonymous" as reader or above.
Open the view in Designer, and Preview it in web browser.
As for the "Couldn't find design note" message - that's not good. You definitely are missing design elements. Whether this is due to a selective replication formula issue, or acl issue, or whatever, is hard to tell. But if you have a Notes thick client and a separate web version, I would recommend different databases (or master templates) and not trying to use selective replication to handle that sort of thing.
As I understand it, you replicated the database then deleted all design elements and manually replaced them by copying from the production web replica. Instead, you should have made a template from the production web database (by doing a design-only copy), and then you should have used the 'Replace Design' feature to update the test web database from that template.
As an aside: an application built the way you describe (two replicas on separate servers, each with a different set of design elements) is a pretty bad implementation. It may have been done in the very early days of Domino, before the "Hide from Notes client" and "Hide from Web" properties were available at the design element level. Or it may have been done deliberately for "security purposes" (which I put in quotes because relying on Domino design element to enforce security on a Domino web application doesn't really make the application any more secure). You may be stuck with this... but you may not be. So before you try to improve or enhance this application, I think you should look into using the "Hide from... " properties on the design elements.
On the other hand, if you stick with the current design, I do want to mention that you're going to need to make sure the ACL settings and selective replication settings on your main and web test replicas match the ACL selective replications settings on the corresponding production replicas. Otherwise, you'll end up with a jumble of design elements when the test databases replicate across servers.
I suggest you to make a new copy of the Notes Database that is on your web server to your test server.
try to open in with your browser and check that all is OK.
open this copy in designer and check that it contains the views that you didn't see previously on test.
I'm not sure that you have really 2 different designs (one for webser different from the one of your main server) so:
- on the main server: open the File/Replication/Option for this application. In advanced, check When web server receives from .... if the design elements is checked.
if not it makes sense that there are TWO different design versions.
Maybe the view you didn't find (on the web server) restricts use? to check this:
- In the view (on the main server) check in the properties of the view the tab with a key "all readers and above". If it's uncheck THIS is the reason why they don't exist on the web server AND that you don't see them in the designer:
If your don't have the role or are not the person which can "who may use this view" you don't see the view and can't copy it.
To correct this simply enter the ACL (file/Application/Access Control) and grant you the corresponding role.
I hope I helped
I'm just learning how to develop an application for Sharepoint.
As far as I can see there are three types of integration into Sharepoint possible:
Sandboxed Solution (limited resource access but easy to install etc)
Farm Solution (installation only available from administrator)
Standard application (maybe .net MVC) with referencing the Sharepoint assembly to access the SPS functionality
Is that correct and complete or am I missing something?
There are quite a few ways to develop for SharePoint depending on your scope, requirements, etc. My knowledge is more in the SP2007 realm than 2010 and my answer reflects that.
JavaScript
Using Content Editor Web Parts you can customize the look of SharePoint, interact with List Data and do some interesting UI effects just using jQuery and the SPServices Plugin. These solutions don't require package and deployment.
Custom Content Type
These can be created through the SharePoint UI or defined through custom XML documents and deployed via WSP. Essentially these are just a collection of field definitions that are related in some logical way. Content types can be added to a list to have all the fields automatically available. In addition, they provide a convenient way of mixing and matching data in the same list (think of roll-ups or backing up list data) though I've never used them in this way.
Event Receiver
Event Receivers can be created to respond to specific events in SharePoint. If you attach an Event Receiver to a list, you can listen for and respond to events like an item or attachment being added, updated, deleted in both a synchronous (-ing) fashion - so you can implement validation and cancel the operation - or asynchronously (-ed) - to do some post-processing once SharePoint is done processing the item. Event Receivers are processed by the Front-End SharePoint server which handled the request which triggered the event. This is different than Timer Jobs and Workflows which are executed by any server in the farm that happens to be available.
Further, Event Receivers can be attached to lists based on their type (apply to all lists of this ID type) or they can be associated with a Content Type and become associated with a list that way (when the content type is added to the list, so too is the event receiver added).
Feature Receivers are a special kind of Event Receiver in that they respond to a Feature
being activated or deactivated to do some additional work. Many people refer to this extra work as Feature Stapling since it lets you perform additional tasks on-demand that couldn't otherwise be done using just XML documents.
Timer Job
A Timer Job is a piece of code that is run on a schedule. It's not executed in the W3WP process like Event Receivers are but rather via the TimerService. Because of this, certain features or values are missing from the SPRequest object. Developing Timer Jobs is more difficult and, in practice, more error prone, more difficult to debug, etc. than Event Receivers.
Workflow
Workflows can be created using SharePoint Designer or Visual Studio. The major difference between these are features available to you at design time. SharePoint Designer Workflows are easier to create and get going but tend to be buggy in SharePoint 2007. Further they are not easily packaged and deployed across environments but rather are associated directly to the list in which you created them (in 2007; in 2010 there is extended capability to allow packaging or even migration into Visual Studio for more complicated customization).
Using Visual Studio gives you more depth and capability but like Timer Jobs they are often difficult to "get right" and they are also processed by the Timer Service process.
Web Part
A custom Web Part is very similar to a regular ASP.NET web part with some extended capability within the SharePoint context. You have access to the SPRequest object and thus all the contextual information (current user, current list/web/site, etc.) to do your work. You can access external databases, make use of most ASP.NET controls, etc.
Custom ASPX Page
If a Web Part isn't sufficient for your needs or you want control over the full page, you can create SharePoint-enabled web pages. These are standard ASP.NET pages decorated with the proper SharePoint master page and deployed into a subdirectory of the hive LAYOUTS directory. With this you have similar access to the current request state as with a Web Part but you have more control over the entire page render.
Custom Web Application
If you have need for a standalone application, you can still take advantage of SharePoint's authentication and authorization tools without running directly in its context. To do this, create an IIS Web Application and set the Application Pool Identity to the same as SharePoint. Alternatively you could make a virtual directory within your SharePoint application pool but this is generally not recommended. You will still be constrained to using the .NET Framework 2.0 runtime if you want to use the SharePoint Object Model at all. This setup seems rarely used in the field since most of the time you can accomplish your needs by just using custom ASPX pages or web parts.
Regarding your specific questions:
Sandboxed solutions are just a special type of solution that restricts the namespaces your web part, etc. have access to. For instance your code can't reach out to access lists outside of its permission area. It can't send email on your behalf. You can increase your rights by using custom permission sets but this is an advanced topic. I just wanted to point out "sandboxed solution" isn't a type in and of itself, it just describes a restriction where previously none existed (SP 2007 GAC-deployed solutions).
Regarding your question regarding an MVC application using the SharePoint Object Model, like I mentioned you are still restricted to running in .NET 2.0 runtime.
EDIT: I forgot (at least) one more option!
List Service / Other ASMX Services
SharePoint has a number of web services you can consume to interact with Lists among other things. In this case, your application can be developed using any technology (or runtime!) you wish as long as it knows how to consume the ASMX services. The functionality available isn't as rich as using the Object Model directly (which is why I often forget to consider it) but it does allow your code to be more decoupled from the SharePoint environment itself. In 2010 there are a lot more options for Client Services to provide even greater functionality.
For developing a solution in visual studio you can go for Sandbox solution and farm solution. If you are having SharePoint 2013, then you will have another better option which is App Part development.
Since Sandbox solution is depricated from SharePoint 2013 onwards, i suggest you should not go with Sandbox solutions. Better to go with App Part development.
I've built a SharePoint user control (not a web part) and am deploying it via Solutions, Features, etc.
It's a commercial component and I want to be able to store license information once it's registered. I've got all the licensing stuff down and working, however, I am trying to find a "global" (i.e. farm level) place to store the information (so it works on multi-server farms).
This is intended to be a commercial component so I have no control over security policies, application pool accounts, etc. I need it to work without admins needing to reconfigure their farms.
I've considered:
Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.
Hierarchical Object Store - Several security gotchas - Namely app pool needs access to Config database (which many environments won't allow)
Root site property bag - Possible. I can update all the Root Sites Properties at the time of registration, but what happens when new web apps are created? User has to register component for each web app?
Registry, file system - Not persisted across servers
Custom DB - Seems like a lot of places for this to fail.
I know other commercial vendors are doing it somehow.
Any ideas?
Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.
There are many many different opinions about putting your configuration stuff in web.config. Personally, i would NOT recommend it, because SharePoint is automatically pushing changes to it and you can't really control what's going on.
I've had similar requirements, but at a SiteCollection level. What i did was creating a simple custom list with 2 columns (Key, Value) at the root of my SiteCollection. Within my code, i hardcoded the name of the list and used elevated privileges (because i set the list permissions to admin-only) to access the values i needed.
You could basically do the same, but not at the root of the SiteCollection level, but in the Central Administration. This way, you can access the configuration list from anywhere within SharePoint.
Another idea would be setting up a simple configuration database and then use a custom web-service (which is deployed within SharePoint) to get it's values. However this adds quite a lot of overhead to such a "simple" task and will get you in a lot of trouble without proper exception handling/logging.