ĐÀO TẠO DOANH NGHIỆP : SỞ KHOA HỌC CÔNG NGHỆ TỈNH ĐỒNG NAI

ENTERPRISE TRAINING: DONG NAI DEPARTMENT OF SCIENCE AND TECHNOLOGY.

HÌNH ẢNH TẬP HUẤN LỚP SHAREPOINT WORKFLOW VÀ KIẾN TRÚC SHAREPOINT

PHOTOS OF SHAREPOINT WORKFLOW AND ARCHITECTURE CLASS.

HÌNH ẢNH TẬP HUẤN LỚP SHAREPOINT WORKFLOW VÀ KIẾN TRÚC SHAREPOINT

PHOTOS OF SHAREPOINT WORKFLOW AND ARCHITECTURE CLASS.

Wednesday, June 4, 2014

Save List Template STP to Retain Lookup Column Data


1.  Create custom lists, named is Provinces and input data
2.  Create custom list Employees, and create column is Province then input data
3.  Save Provinces and Employees as list template in same name (Provinces.stp, Employees.stp), check Include Content
4.  Open another site collection
5.  Upload Provinces.stp to list template
6.  Create list provinces base on Provinces.stp => data is same
7.  Opening Firefox >> Open Provinces lists >> Go to list settings  >> on url copy list’s GUID {50504A28-68EA-45EC-8611-0D50DB977B5F}
8.  Rename the [yourlist].stp file to [yourlist].cab so Windows can open it.
9.  Extract it
10.Open the file with notepad ++ or notepad. Search keyword “Province”
11.Replace Guid ID “{52350695-0105-4175-8b51-e04995542744}” by {50504A28-68EA-45EC-8611-0D50DB977B5F}
12.The result as
13.Save the manifest.xml file.
14.Open a VS.NET command prompt.Run the makecab command as follows: C:\Windows\system32>makecab C:\MicrosoftTechnology\manifest.xml C:\MicrosoftTechnology\Employees.stp
15.Upload Employees.stp to list template.
16.Create a new list based upon the new STP file.
17.The lookup column on the new list should retain all the data that was in the source list.


Sharepoint Architecture Template Part 1


SOFTWARE ARCHITECTURE 
DOCUMENTATION FOR PORTAL

APPLY FARM IN SHAREPOINT

Revision: 0.1



DOCUMENT CHANGE LOG
Revision
Description
Author
Date
Approved
Date












































































































 

Table of contents




List of figures

1      Introduction

·      PORTAL = Automotive Supply Chain Portal, a private community site that internal and external parties need to have an account to login and contribute information.
o     Internal parties refer to MSTECHSHARING user, such as: developer, support rep, sales rep, and marketing.
o     External parties refer to MSTECHSHARING customers that can be 1st tier-supplier and 2nd tier-supplier.

1.1   Purpose

This document defines the MSTECHSHARING Architectural Design based on the MSTECHSHARING Functional Design Specifications. This Architectural Design document shall not repeat those design specifications. It details the high level key system components and also the deployment architecture to meet the functional design specifications. Key technologies are identified for each MSTECHSHARING service component.
The MSTECHSHARING architectural design strives to be both scalable and flexible. The system design is component based and provides great flexibility in deployment. The technical overview defines major system components and related technologies. It also provides deployment architecture.
The use cases mentioned in this document capture the specific functional and business rules applied on each independent business process activity and should enable the system users to validate the functionalities supported implicitly and explicitly by the system.  The use cases also identify the end users of the system.

1.2   Target audience

This document is developed by MSTECHSHARING Portal development team and will be used by project stake holders for development and maintenance.

1.3   Definitions

TBD

1.4   Scope

This document is applied to PORTAL project

1.5   Acronyms, and Abbreviations

Abbreviations and definitions used throughout the document are presented here to aid the reader.
Table 1: Acronyms and Abbreviations
Term
Definition
SRS
Software Requirement Specification
API
Application Programming Interface






1.6   References

1.7   Overview

This document has following contents:
o     Section 1: Show document purposes and overview.
o     Section 2: Describe system overview and features.

2      Overall Description

2.1   System overview

2.1.1     MSTECHSHARING Technology Overview

MSTECHSHARING’s architecture design recommendations are the Functional Requirements document which supported for MSTECHSHARING’s customer and MSTECHSHARING’s staff, so we choose “SharePoint Technology” to manage information of each customer

2.1.2     Architectural Strategy Statement

To meet the MSTECHSHARING’s core requirements of a robust, scalable architecture, a combination of technologies has been recommended. We recommend this flexible suite of solutions to take advantage of the strengths of SharePoint

2.1.3     Inputs

Overview (datetime).
MSTECHSHARING SRS (datetime).

2.2   Software’s limit and storage data

2.2.1     Software limit

2.2.2     Storage data

3      Recommended Architectural Components

3.1   Standard Farm model

3.1.1     Overview

3.1.2     Technology Considerations

3.1.3     Software and Hardware Requirements

4      SharePoint 2010 farm topology

4.1   Define web server, application server, Database server, query server, crawl server

4.1.1     Web server

4.1.2     Application server

4.1.3     Database server

4.1.4     Query server (Query component)

4.1.5     Crawl server (Query component)

4.2   How many topologies for SharePoint Server 2010 and how many server on each topology

4.2.1     Limited Deployments

4.2.2     Small Farm Topology Deployments

4.2.3     Medium Farm Topology Deployments

4.2.4     Large Farm Topology Deployments

4.3   Server role in each topology: front-end, back-end, database

4.3.1     Web server roles

-         Host Web pages, Web services, and Web Parts that are necessary to process requests served by the farm.
-         Direct requests to the appropriate application servers.
-         This role is necessary for farms that include other SharePoint Server 2010 capabilities. In dedicated search service farms, this role is not necessary because Web servers at remote farms contact query servers directly.
-         In small farms, this role can be shared on a server with the query component.

4.3.2     Application server roles

4.3.3     Database server roles

4.4   How to solve: we use farm model because number of user and Data storage are large

4.4.1     Starting point architecture follows number of items

4.4.2     At current time:

4.4.2.1      How to setup two tiers limited deployment:

4.4.3     At next time:

4.4.3.1      How to setup two tiers small farm:

4.4.4     In the future


4.4.4.1      How to setup three tiers: