Multiuser functionality in SAP Data Services
In this post you will create two local repositories and one central repository and perform the tasks associated with sharing objects using Data Services.
You can also check the post Central Repository in BODS for more details.
Multiuser Development
This section introduces you to Data Services features that support multiuser development. Data Services enables multiple users to work on the same application. It enables teams of developers working on separate local metadata repositories to store and share their work in a central repository.
You can implement optional security features for central repositories.
Introduction
Data Services can use a central repository as a storage location for objects. The central repository contains all information normally found in a local repository such as definitions for each object in an application.
In addition, the central repository retains a history of all its objects. However, the central repository is merely a storage location for this information.
To create, modify, or execute objects such as jobs, always work in your local repository and never in the central repository.
Using a central repository, you can:
• Get objects into the local repository
• Check out objects from the central repository into the local repository
• Check in objects from the local repository to the central repository
• Add objects from the local repository to the central repository
The functionality resembles that of typical file-collaboration software such as Microsoft Visual SourceSafe.
When you get an object, you are copying the object from the central repository into your local repository, and if the object already exists in your local repository, it overwrites that object.
You can also check out objects from the central repository into your local repository. When you check out an object, you copy the object into your local repository and "lock" it, preventing other users from checking out that object. Other users can still get (copy) a checked-out object. However, at any given time, only one user can check out an object.
After checking out an object from the central repository, you must eventually check it back in to the central repository. When you check in an object, Data Services creates a new version of the object, saving your changes for revision control. After you check in an object, other users can then check it out.
Note:
If an object is checked out by another user and you get a copy of the checked-out object and make changes to that object in your local repository, then those changes are saved only in your local repository.
To save changes to an object in the central repository, you must check out the object, make the changes, and check it back in.
At any time, you can add objects from your local repository to the central repository. However, if an object already exists in the central repository, you cannot add it again.
The central repository retains each object's history. The object's history lists all versions of the object.
If you find you made a change that did not work as planned, you can revert to a previous version of the object.
Exercise overview
In these exercises, two developers use a job to collect data for their company's HR department. Each developer has a local repository and they both share a central repository. Throughout the exercises, the developers modify the objects in the job and use the central repository to store and manage the modified versions of the objects. You can perform these exercises by "playing" both developers, or do them with another person, each of you assuming one of the developer roles.
Preparation
Before doing these exercises, you must set up a multiuser environment. If you have worked on previous sections in this tutorial, you already have a database with a user name and connection for a local repository.
For Oracle, you can use the same database for the additional repositories listed in the following table. However, you first must add these user names, passwords, and appropriate access rights to your existing database. When you create these additional repositories, Data Services qualifies the names of the repository tables with these user names.
| User Name | Password |
| central | central |
| user1 | user1 |
| user2 | user2 |
For Microsoft SQL Server, you must create a new database for each of the repositories listed in the previous table. When you create these user names and passwords, ensure that you specify appropriate server and database roles to each database.
To create a central repository
Create a central repository if you did not create one during installation.
1. Close the Designer if it is open.
2. From the Start menu, click Programs > SAP BusinessObjects Data Services 4.0 > Data Services Repository Manager.
3. In the "Repository Manager" dialog box, select the database type and enter the connection information for the central repository.
4. For both User and Password, enter central.
Note:
This section instructs you to use specific user names and passwords. By using predetermined accounts and passwords, you can more easily role-play during the tutorial exercises. You will use two user accounts and a central repository account, logging in and out of them often. So to help avoid confusing accounts, use the names provided.
5. For Repository type, click Central.
Note:
This section does not use the Enable Security option.
6. Click Create.
Data Services creates repository tables in the database you identified.
7. Click Close.
Creating two local repositories
In a multiuser environment, many users can access a single central repository. Each user must have his or her own local repository in which to work. If you did not create two local repositories during installation, create them using the following procedure.
To create two local repositories
1. From the Start menu, click Programs > SAP BusinessObjects Data Services 4.0 > Data Services Repository Manager.
2. Enter the database connection information for the local repository.
3. Type user1 for both User and Password.
4. For Repository type, click Local.
5. Click Create.
6. Type user2 for both User and Password.
7. Click Create.
8. Click Close.
Associating repositories to your job server
You must associate the local repositories to a job server in order to execute jobs.
To associate repositories to a job server
1. From the Start menu, click Programs > SAP BusinessObjects Data Services 4.0 > Data Services Server Manager.
2. In the "SAP BusinessObjects Data Services Server Manager" dialog box, on the Job Server tab, click Configuration Editor.
3. In the "Job Server Configuration Editor", select the Job Server Name and click Edit.
4. In the "Job Server Properties" dialog box, in the Associated Repositories area, click Add.
5. In the Database type list in the Repository Information area, select the appropriate database type for your local repository.
6. Complete the appropriate connection information for your database type.
7. Type user1 in both the User name and Password fields.
8. Click Apply. You should see databasename_user1 in the list of Associated Repositories.
9. Repeat steps 4 through 8 to associate user2 to your job server.
10. Click OK to close the "Job Server Properties" dialog box.
11. Click OK to close the "Job Server Configuration Editor".
12. Click Close and Restart on the Server Manager dialog box.
13. Click OK to confirm that you want to restart the Data Services Service.
Defining connections to the central repository
Each local repository requires connection information to any central repository it must access.
To define connections to the central repository
1. Start the Designer and log on to get a list of local repositories.
2. Log onto the user1 repository.
3. From the Tools menu, click Central Repositories.
In the Designer list, the Central Repository Connections option should be selected.
4. Click Add.
5. In the "Connect to Central" repository dialog box, select Central from the list of available repositories and click OK.
6. Click OK.
7. Click Yes at the prompt to overwrite the Job Server option parameters.
8. Exit the Designer.
9. Start Data Services log onto the user2 repository.
10. Repeat steps 2 through 8 to establish a connection between the user2 local object library and the central repository.
Working in a multiuser environment
After setting up the multiuser environment, you can begin working in it. Remember, Data Services adds all objects to your local repositories.
The tasks in this section include:
• Importing objects into your local repository
• Activating a connection to the central repository
• Adding objects to the central repository
• Checking out objects from the central repository
• Checking in objects to the central repository
• Undoing check out
• Comparing objects
• Checking out without replacement
• Getting objects
• Using filtering
• Deleting objects
To import objects into your local repository
For these exercises, you will use a job containing previously created work flows and data flows. To use this job, complete the next procedure.
1. Start Data Services and log in as user1 with password user1.
Notice that the type of repository, connection, and user ID display above the object library. Use this information to confirm that you logged in to the correct repository.
2. In the object library, right-click in a blank space and click Repository > Import From File.
3. Navigate in your Data Services installation directory to <your .atl file> and open it.
4. In the warning window, click OK.
Data Services imports the selected file.
5. In the object library, view the Jobs, Work Flows, and Data Flows tabs to verify that the
file imported the objects listed in the following table.
| Tabs | Object names |
| Jobs > Batch Jobs | JOB_Employee |
| Work flows | WF_EmpPos |
| WF_PosHireDate | |
| Dataflows | DF_EmpDept |
| DF_EmpLoc |
Activating a connection to the central repository
In a multiuser environment, you must activate a central repository before working with it.
To activate a connection to the central repository
1. From the Tools menu, click Central Repositories.
The Central Repository Connections option should be selected in the Designer list.
2. In the Central repository connections list, select Central and click Activate.
Data Services activates a link between the user1 repository and your central repository.
3. Open the central object library by clicking the Central Object Library icon on the toolbar. Note that this button acts as a toggle for displaying the window.
The central object library looks like the local object library.
To see periodic changes, refresh the central object library by clicking the Refresh icon on its toolbar.
Adding objects to the central repository
After importing objects into the user1 local repository, you can add them to the central repository for storage. When adding objects to the central repository, you can add a single object or the object and its dependents. All projects and objects in the object library can be stored in a central repository.
To add a single object to the central repository
1. Click the Formats tab in the user1 local object library.
2. Expand Flat Files to display the file names.
3. Right-click NameDate_Format and click Add to Central Repository > Object.
Data Services prompts you to add optional comments about adding this object to the central repository.
4. Click OK.
Data Services adds the object to the active central repository. The "Output" window opens to indicate that Data Services added the object successfully.
Note:
The Add to Central Repository command will not be available if the object already exists in the central repository.
5. If it is not already open, open the central object library by clicking its icon on the toolbar.
Note:
You can add the central object library to the Designer window by dragging it over the window and one of the arrows that each represent a location where you can place the library. Each arrow displays the shape and location of where the library will fit. To separate again, drag the central object library away from the Designer window.
6. Click the Formats tab of the Central object library and verify that NameDate_Format is listed under Flat Files.
To add an object and its dependents to the central repository
1. Click the Work Flows tab in the user1 local object library.
2. Double-click WF_EmpPos and notice that DF_EmpDept and DF_EmpLoc are inside it.
3. Right-click WF_EmpPos and click Add to Central Repository > Object and dependents. The Comments window opens.
4. In the comments field, type:
Adding WF_EmpPos, DF_EmpDept, and DF_EmpLoc to the central repository.
5. Click Apply to all.
6. Close the "Output" window. (The toolbar also has a toggle button for the Output window.)
7. In the central object library, click the Data Flows tab and verify that the DF_EmpDept and DF_EmpLoc data flows are listed under Data Flows.
8. Click the Work Flows tab of the central object library.
9. In the Work Flows tab of the local object library, drag the WF_PosHireDate work flow to the work flow tab of the central object library, which will add it and its data flow (DF_PosHireDate) to the central repository.
10. In the "Version Control Confirmation" window, click Next.
11. In the "Datastore Options" window, click Finish.
Note:
If you see an alert that some objects already exist in the repository, click Yes to continue.
12. In the "Comments" dialog box, type:
Adding WF_PosHireDate and DF_PosHireDate to the central repository
13. Click Apply to all.
14. Click the Data Flows tab in the central object library and verify that the DF_PosHireDate data flow
is listed under Data Flows.
Now that the central repository contains all objects in the user1 local repository, developers can check out, check in, label, and get those objects.
Checking out objects from the central repository
When you check out an object, it becomes unavailable to other users. Other users can view the object but cannot make changes to it. You can check out a single object or check out an object with all of its dependents.
If you check out a single object such as WF_EmpPos, then you cannot change its dependents (such as DF_EmpDept) and save those changes in the central repository. You can only save changes to dependent objects that are not checked out in your local repository.
Alternatively, if you check out WF_EmpPos with all of its dependents, you can make changes to the dependent objects (DF_EmpDept or DF_EmpLoc). Because you checked out the dependents, you can save changes in both the central repository and your local repository.
To check out an object and its dependent objects
1. Open the central object library.
2. In the central object library, right-click the WF_EmpPos work flow.
3. Click Check Out > Object and dependents.
Alternatively, you can select the object in the central object library, then click the Check out object and dependents icon on the central object library toolbar.
Data Services copies the most recent version of WF_EmpPos and its dependent objects from the central repository into the user1 local repository. A red check mark appears on the icon for objects that are checked out in both the local and central repositories.
While user1 has the WF_EmpPos work flow checked out, he or she can modify it or its dependents in the user1 local repository.
To modify dependent objects in the WF_EmpPos work flow
1. In the local object library, click the Data Flows tab.
2. Open the DF_EmpDept data flow.
3. In the DF_EmpDept workspace, double-click the query icon's name to open the query editor.
4. Change the mapping: Right-click FName in the target schema (Schema Out) and click Cut.
5. Click the Back arrow in the icon bar to return to the data flow.
6. Open the DF_EmpLoc data flow.
7. Click the query icon's name to open the query editor.
8. Change the mapping:
a. Right-click FName in the target schema and click Cut.
b. Right-click LName in the target schema and click Cut.
9. From the Project menu, click Save All (even though there are no actual projects open).
10. Click OK to save your changes.
Next, user1 will check in one of the modified objects.
Checking in objects to the central repository
You can check in an object by itself or check it in along with all associated dependent objects. When an object and its dependents are checked out and you check in the single object without its dependents, the dependent objects remain checked out.
To check in a single object
1. Open the central object library.
2. Right-click the DF_EmpDept data flow in the central object library and click Check In > Object.
A Comment window opens.
3. In the comments field, type:
Removed FName and LName columns from NAMEDEPT target table
4. Click OK.
Data Services copies the object from the user1 local repository to the central repository and removes the check-out marks.
5. In the central object library window, right-click DF_EmpDept and click Show History.
6. Close the "History" window and ExitData Services.
The next portion of this exercise involves a second developer (user2).
To set up the second developer's environment
1. Start the Designer and log into the user2 repository.
2. Import the multiusertutorial.atl file.
3. Activate the connection to the central repository.
4. Open the central object library.
5. Notice that you cannot check out DF_EmpLoc because it is still checked out by user1.
Undoing check out
Suppose you check out DF_PosHireDate from the central repository and begin modifying it in your local repository. Then you realize you are working with the wrong data flow—you intended to modify DF_EmpLoc. In this situation, you can undo the check out of DF_PosHireDate from the central repository.
When you undo a check out, you leave the object in the central repository as is. Data Services does not save changes or create a new version in the central repository. Your local repository, however, retains any changes you made. To undo changes in the local repository, you must get a copy of the current, unchanged object from the central repository.
Undo check out works for both a single object as well as objects with dependents.
In the next exercise, user2 will check out objects from the central repository, modify the objects in the user2 local object library, and then undo the check out.
To check out and modify the DF_PosHireDate data flow
1. Open the central object library.
2. In the central object library, right-click the DF_PosHireDate data flow and click Check Out > Object.
3. In the local object library, open the DF_PosHireDate data flow.
4. Click the query icon's name.
5. Change the mapping: Right-click LName in the target schema and click Cut.
6. From the Project menu, click Save All.
7. Click OK.
Now suppose you realize you modified the wrong data flow. You intended to modify the DF_EmpLoc data flow instead.
To undo a check out of the DF_PosHireDate data flow
In the central object library, right-click DF_PosHireDate and click Undo Check Out > Object.
Data Services removes the check-out symbol from DF_PosHireDate without saving changes to it in the central repository. In the next procedure, you will verify this by comparing the copy of DF_PosHireDate in the user2 local object library to the version of DF_PosHireDate in the central repository.
Comparing objects
Data Services allows you to compare two objects from local and central repositories to determine the differences, if any, between those objects.
In this exercise, the second developer will compare the copy of the DF_PosHireDate data flow in the user2 local object library to the version of the DF_PosHireDate data flow in the central repository to verify the undo check-out performed in Undoing check out.
To compare the two objects
1. From the user2 local object library, right-click DF_PosHireDate and click Compare > Object with dependents to Central.
The Difference Viewer opens in the workspace.
2. The query icon in the left pane shows the consolidated symbol, so click the plus symbol to expand the object tree and find the changed object.
The Differences Viewer indicates that the LName column is missing in the local copy, but the central repository copy still shows the previous version of DF_PosHireDate with the LName column present.
Data Services shows the differences between the two objects in the panes. If there are no differences, the status bar below the panes indicates Difference [ ] of 0. If there are differences between the objects, Data Services indicates each difference with a symbol and highlights the affected objects.
The left side of the status bar shows the key to the symbols and the meaning of each, as described in the following table.
| Icon | Difference | Description |
 | Deleted | The item does not apper in the object in the rignt pane. |
 | Changed | The differences between the items are highlighted in blue (the default) text |
 | Inserted | The item has been added to the object in the right pane. |
 | Consolidated | This icon appears next to an item if items within it have differences. |
| Expand the item by clicking its plus sign to view differences. |
Checking out without replacement
Suppose you continue to work in the user2 local object library and modify the DF_EmpLoc data flow.
After modifying it, you want to place your copy of this data flow in the central repository. However, you never checked out DF_EmpLoc from the central repository. If you now checked out DF_EmpLoc from the central repository, Data Services would copy the most recent version from the central repository into the user2 local object library, overwriting your local copy. All your work on your copy of DF_EmpLoc would be lost.
Data Services provides an option that allows you to check out an object without copying the latest version of the object from the central repository into your local repository. This option is called checking out without replacement. You can check out a single object or an object and its dependents without replacement.
In the next exercise, the second developer will modify the DF_EmpLoc data flow in the user2 local object library, check it out without replacement, and then check his unaltered, local copy of the data flow back in to the central repository.
To modify the data flow DF_EmpLoc
1. In the local repository, open the DF_EmpLoc data flow.
2. Click the query icon's name to open the query editor.
3. Change the mapping: Right-click FName in the output schema and click Cut.
4. From the Project menu, click Save All to save your work.
Now you realize that you want to place your copy of DF_EmpLoc in the central repository.
To check out an object without replacement
1. Open the central object library.
2. In the central object library, right-click DF_EmpLoc and click Check Out > Object without replacement.
Now the DF_EmpLoc data flow in the central repository is "locked" so other users cannot check it out, but the copy of the DF_EmpLoc data flow in the user2 local object library remains unchanged.
To check in the DF_EmpLoc data flow
1. From the central repository, check in the DF_EmpLoc data flow. In the Comment field of the "Check In" window, type Removed FName from POSLOC, and click OK.
(See Checking in objects to the central repository.)
Now the central repository contains a third version of DF_EmpLoc. This version is the same as the copy of DF_EmpLoc in the user2 local object library.
2. Compare the copy of DF_EmpLoc in the user2 local object library with the third version of DF_EmpLoc in the central repository to verify they are the same.
(See Comparing objects.)
3. Exit Data Services.
Next, the first developer (user1) will check in the DF_EmpDept data flow into the central repository.
Then no objects will be checked out of the central repository.
To check in DF_EmpDept and WF_EmpPos
1. Start the Designer and log back in as user1 with password user1.
2. Open the central object library.
Note:
Remember to reactivate the connection to the central repository from user1 (see Activating a connection to the central repository).
3. Check in DF_EmpDept, and type Removed FName from NAMEDEPT in the Comment field. (See Checking in objects to the central repository.)
4. Click Yes in the "Check In Warning" window.
Now the central repository contains three versions of DF_EmpLoc, two versions of DF_EmpDept, and one version of DF_PosHireDate.
5. To confirm, right-click each object and click Show History.
6. Check in WF_EmpPos without dependents and type Modified DF_EmpLoc and DF_EmpDept in the Comment field.
Getting objects
You might want to copy a specific version of an object from the central repository into your local repository. Getting objects allows you to do so. When you get an object, you copy a version of that object from the central repository into your local repository, replacing the version in your local repository.
Getting an object is not equivalent to checking out an object.
To get the latest version of an object
1. In the local object library, open the DF_EmpLoc data flow.
2. Click the query icon's name to open the query editor.
3. Make note of the Pos and Loc columns in the target schema (POSLOC target table.).
4. Click the Back arrow in the icon bar to return to the data flow.
5. In the central object library, right-click the DF_EmpLoc data flow in the central object library and click Get Latest Version > Object.
Data Services copies the most recent version of the data flow from the central repository to the user1 local repository.
6. Open the DF_EmpLoc data flow.
7. Click the query icon name.
8. Notice the LName, Pos, and Loc columns in the target schema (POSLOC target table.).
The latest version of DF_EmpLoc from the central repository overwrites the previous copy in the user1 local repository.
9. Click the Back arrow in the icon bar to return to the data flow.
To get a previous version of an object
When you get a previous version of an object, you get the object but not its dependents.
1. In the central object library, right-click the DF_EmpLoc data flow and click Show History.
2. In the "History" window, click the first version of the DF_EmpLoc data flow.
3. Click Get Obj By Version.
4. Close the "Show History" and the "Output" windows.
5. Open the DF_EmpLoc data flow.
6. Click the query icon name.
7. Notice the FName, LName, Pos, and Loc columns in the target schema (POSLOC target table).
The first version from the central repository overwrote the last copy of the DF_EmpLoc data flow in the user1 local repository.
Using filtering
You use filtering to select which dependent objects you want to include, exclude, or replace when you add, check out, or check in objects in a central repository.
When multiple users work on an application, some objects can contain repository-specific information.
For example, datastores and database tables might refer to a particular database connection unique to a user or a phase of development. After you check out an object with filtering, you can:
• Change datastore and database connection information to be specific to your local repository
• Change the root directory for files associated with a particular file format to a directory on your local repository
• Replace or exclude specific dependent objects when you check in the object
To check out objects with filtering
1. Start the Designer and log in as user2 with password user2.
2. Open the central object library.
3. Right-click WF_EmpPos and click Check Out > With filtering.
The "Version Control Confirmation" window shows your selected object and any dependent objects.
4. Click the plus symbol to expand the Flat Files list.
5. Click NamePos_Format, and in the Target status list click exclude.
NamePos_Format will not be checked out.
6. Click Next.
7. The "Datastore Options" window shows any datastores used by the object. This window only opens if the objects that you are adding, checking in, or checking out include a datastore. Click Finish.
Deleting objects
You can delete objects from the local or the central repository.
To delete an object from the central repository
1. Still logged on as user2, open the central object library.
2. On the Work Flows tab, right-click WF_PosHireDate and click Delete. Click OK to confirm deletion.
When you delete objects from the central repository, you delete only the selected object and all versions of it; you do not delete any dependent objects.
3. In the central object library, click the Data Flows tab and verify that DF_PosHireDate was not deleted from the central repository.
When you delete an object from a central repository, it is not automatically deleted from the connected local repositories.
4. Open the Work Flows tab in the local object library to verify that WF_PosHireDate was not deleted from the user2 local object library.
To delete an object from a local repository
1. Click the Data Flows tab in the user2 local object library.
2. Right-click DF_EmpDept and click Delete.
When you delete an object from a local repository, it does not get deleted from the active central repository. In fact, you can get or check out an object from the central repository to reinsert it.
3. Open the central object library.
4. Click Refresh on the toolbar.
5. In the central repository, click the Data Flows tab and verify that DF_EmpDept was not deleted from the central repository.
6. Exit Data Services.
Comments
Post a Comment