For example, you could use this element to store default values you want to pass to the association form when it is displayed. Your form can then load that association data from the workflow template.
In general, the custom workflow association form must perform the following actions: Examine the value of the GuidAssoc parameter to determine whether the user is adding a new workflow association or editing an existing workflow association. If the user is adding a new workflow association, call the AddWorkflowAssociation method to create a new workflow association.
If the user is editing an existing workflow association, call the UpdateWorkflowAssociation method to update that workflow association. Create the task list for the workflow, if it does not already exist. Use the data collected from the user to set properties of the SPWorkflowAssociation object, as appropriate.
Create the workflow history list, if necessary. Specifying Initiation Forms If you want your workflow to have an initiation form, you must set the InstantiationURL attribute of the Workflow element in the workflow template definition. Set this element to the form you want to use to collect the workflow initiation data, as shown in the following example. ID The ID of the list item on which the workflow is started. Source The page from which the user started the workflow.
In general, the form must perform the following actions: Locate the SPWorkflowManager object for the current site. Use the eventData parameter to pass the initiation form data in string format. Return the user to the source page from which he or she started the workflow. No comments:. Tasks: The tasks list is used to track open tasks related to the clinical trial protocol process.
Document Discussions: This discussion board is used to hold newsgroup-style discussion on topics relevant to the client trial protocol team. Skip to content Description of Template The Clinical Trial Initiation and Management SharePoint template helps companies manage the clinical trial protocol — the main deliverable of the clinical trial initiation phase. Using this workflow automatically generates a number of Protocol Documents that can be used to help manage the clinical trial process.
Once a clinical trial is created, these documents can be modified, approved and updated by members of the team. Create additional Protocol Documents: Microsoft provides five standard document templates for each Clinical Trial Protocol, but trial managers may wish to create or upload additional documents, which can be managed through the application template.
Each document can be placed under a particular clinical trial, assigned to an owner, given an appropriate status and given a due date, if appropriate. Calendar Functionality: A simple calendar can be used to track major events and activities related to the clinical trials that are planned or in progress.
Document Discussions: To enable collaboration between team members, threaded discussions are enabled. However, Office SharePoint Server is much more than that. The Office team made significant investments in many other areas to give MOSS extra dimensions in Web content management, document and records management, business process integration and forms, and business intelligence. In this article I'll describe the basic architecture of MOSS and explore the various opportunities for developers to build portal sites and business solutions.
NET 2. NET components such as server-side controls and custom Web Parts as well as custom components that utilize WSS features like custom list definitions, document libraries, event handlers, and workflows. As a developer, it's also important to set your expectations accordingly about what you'll need to do to get a MOSS solution up and running. In some scenarios you can get an entire business solution up and running without ever writing any custom code.
This is quite different from developing directly on the ASP. NET platform by itself where you need Visual Studio to put together the simplest site. The Microsoft Office team promotes a philosophy in which you begin building a MOSS business solution with an assemble-and-configure mentality. Once you determine the MOSS features and services you want to utilize, you can create a new portal site and do as much "development" as possible simply by configuring services through browser-based administrative pages.
If you are going to succeed at building MOSS-based solutions, it's important to embrace this assemble-and-configure mindset. However, there will inevitably be times when this mindset doesn't cut it for a particular solution. Then you can put your developer's hat back on and crank up Visual Studio to create many of the custom component types that are discussed here. For example, SPS provides its own separate administrative Web application for provisioning and configuring portal sites.
MOSS, on the other hand, doesn't require its own separate administrative application. SPS builds its portal site infrastructure around the concepts of areas and listings. So areas and listings have been eliminated in MOSS and replaced with a portal infrastructure that was designed and implemented much more in line with WSS best practices.
This provides more flexibility because you can host hundreds of portal sites inside a single IIS Web site. Remember that in WSS 3. When creating a new MOSS portal site, you typically use one of the portal site templates created by the Office team.
If you want to create a new portal site of this type, you can use the code shown in Figure 2 , which works against the object model provided by WSS 3. The Office team has also provided new site templates to create child sites within a portal site collection, such as Report Center and Search Center.
This new SSP architecture was designed to replace the shared services infrastructure of SPS to provide greater flexibility in deployment and configuration. For example, it's possible to create two different SSPs within the same server farm, each with its own configuration, as shown in Figure 4. As a result, the search results from within one portal site might be very different from the search results within another portal site if they are associated with different SSPs that have been configured to have different content sources.
User profiles are a MOSS feature that has been carried over from SPS to track information about the users within an organization. Profiles allow users to learn more about the people they work with and see how everyone fits into their company's organization chart.
User profiles also provide the foundation for other MOSS features such as audience targeting and personal sites. MOSS provides several standard pages and Web Parts to display the information tracked within user profiles. As with SPS , user profiles can be extended with custom properties to track user data for domain-specific business solutions. However, MOSS enhances custom properties by allowing for multivalued properties and properties defined with open or closed vocabularies.
When it's time to write custom code against a user profile, you can program against the UserProfileManager to load and inspect the property values for a specific user.
Figure 6 shows a simple example of code written in the RenderContents method for a custom Web Part to display all property values within the user profile of the current user. Audience targeting is another valuable feature that has been carried over from SPS You can create an audience by specifying criteria to define a subset of users. For example, you can create a Sales audience that is defined as all the users who are members of an Active Directory group named Sales.
You could define another audience named Carpool as the set of users with the custom Carpool property's value set to True. Once you have defined an audience, you can then configure a Web Part to conditionally display its content only when the current user is a member of that audience. Audience targeting is a great way to show privileged users links to secured pages while hiding these links from non-privileged users who would receive Access Denied errors when attempting to follow them.
This makes it straightforward to target content to those users who need it while hiding that content from users who either don't want to or shouldn't see it. One more feature carried over from SPS that is built on user profiles is personal sites. When personal sites are enabled within an SSP, MOSS will provide each user with his own personal site—a My Site—that is provisioned on demand the first time it is used.
Personal sites enable users to edit certain aspects of their user profiles to better describe themselves to their coworkers. A personal site has a public aspect, which makes it easy for a user to share data and documents with other users within the organization. A personal site also has a private aspect, allowing a user to store data and documents that are not meant to be shared. SPS search makes it possible to search through, not only content and documents within SPS portal sites and WSS team sites, but also through external content such as Windows file shares, public Microsoft Exchange Server folders, and standard Web sites.
MOSS search was designed to give you these same features in a manner that is more performance oriented and easier to configure. These upgrade problems have been addressed, as the WSS and MOSS search services are now based on the same underlying indexing and search infrastructure, which is an evolved version of what was provided by SPS MOSS search can be configured to run the indexing service and search service on different servers within a farm to increase scalability and throughput.
WSS search is limited to running the indexing service and search service on the same physical server. Configuring MOSS search is an administrative exercise that entails creating and configuring content sources within the scope of a particular SSP.
A content source defines a set of searchable content. However, the SSP administrator must explicitly create and configure additional content sources to support building indexes and searching through external content such as documents in a Windows file share or content from a public Web site.
WSS 3. MOSS goes even further to supply a dedicated child site named Search Center within a portal site collection that provides a specialized user interface for searching, as shown in Figure 7.
You might conclude that companies can take full advantage of MOSS search facilities without ever writing any custom code. For example, you can write a server-side component such as a Web Part or a custom workflow that queries the MOSS search service programmatically and deals with the returned search results in a customized fashion. Likewise, you can create a Windows Forms application that queries the search service from across the network through built-in MOSS Web services.
While SPS made it possible to integrate portal sites with back-end systems, it required you to write custom code to manage connections and retrieve the data you needed to display. Furthermore, the required code changed significantly if you switched between back-end systems from vendors such as SAP and PeopleSoft. The Office team designed the BDC to make things much easier.
The BDC enables you to integrate data from back-end systems without requiring custom code for managing connections and retrieving data. The BDC design is based on standardized metadata that describes the location and format of a back-end system and data entities defined within it.
The BDC also provides an execution component that is capable of reading BDC metadata and that is able to retrieve external data from back-end systems and return that data to MOSS in a standardized format. Figure 8 shows the high-level architecture of the BDC.
As you can see, connectivity between the BDC and traditional line-of-business systems is achieved by using standard Web services. NET providers. When you author metadata for the BDC, you define the data you want to retrieve in terms of entities. For example, you might define a customer as one entity and an invoice as another entity.
The BDC metadata format also lets you define associations between entities in scenarios when there is a one-to-many relationship such as one that might exist between customers and invoices. The definition of a BDC entity contains identifiers, properties, and methods. The methods define how the BDC interacts with entry points exposed by the back-end system.
0コメント