This post explain the process of Exporting Scenarios from DWR to EWR . As Cezar have suggested in previous post of how it is important to have one single DWR ( Developer Work Repository) and multiple EWR [ Execution Work Repository ] , As Multiple DWR can lead to improper code maintains and improper synchronization between the multiple DWR. Read more this post here
In this present example i am moving from my DWR to EWR [ Testing Environment ] .
Generally before the UAT , its important to have an Testing environment where Scenarios functionality, code Testing , Data Validity is tested. I strongly feel that it is import to have such an environment before releasing to UAT so that less codes fail at the UAT and multiple minor issues can be fixed at this stage thus avoiding more failure at the next stages.
In this example i am creating the EWR in the same Master Repository and using a different context and agent but its is not necesarry to do so, if both are in the same box , the only draw back i see is that using the same agent for Development and Testing can lead to performance degradation , but again its the architecture and the requirement which matter requiring to understand in how to handle the resources.
Step 1
– Creating the Execution Work Repository schema, tablespace and other Database permission for users.
Step 2
– Creating the EWR in ODI Topology Manager..
Right click – > Insert Work Repository .
Provide the required Meaningful name , EWR schema user/password created in step 1
Provide the JDBC Driver, URL.
Click Test and Once Successful Click Apply and OK.
Provide the new ID , make sure the ID different from the other DWR created . Select ‘ Execution ‘ type and provide a meaningful Name as that will be your Execution Work Repository Name. click Ok once done.
We have our EWR created
As you can see that in EWR , mostly tables related to Scenarios , Sessions , Sequence , Variables tables are created and the work tables in EWR are less than the DWR since in EWR mostly information related to scenarios, sessions are mattered a lot.
Also EWR , access to Operator , Topology and Security Manager are allowed . As the name suggestion Execution Work Repository so only Scenarios are allowed to be imported into this environment and so designer are not created in EWR .
Step 3
– Logging into EWR Operator.
Now we will move our Scenarios from DWR to EWR
Step 4
– Transfer of Scenarios from DWR to EWR
Log into Operator of DWR .
Right Click on the Scenario to be Exported and selected the Folder.
Always use the insert_update mode so the in the future when you try to insert or update ODI can automatically identify the scenario and make the necessary insertion and updation and less code corruption.
Using Solutions
Solution is great when the client or architecture demans to track each code flow from one environment and to the other ,as solution creates version for insertion and for every transfer so at the end there can be multiple version of the same objects . As i have said before its the requirement that matter , in case if solution have to be used use Description to provide as much details as possible
say for example
Description .
1. Fixed the Invalid_number issue
2. Logic for Data validation is changed by this example and so on.
Doing so can provide more help and information for the administrator or the user in getting older and newer codes into the other environment as the demand requires.
Go the DWR operator – > Insert Solution
Provide the Solution Name and drag in the scenario into Principal Elements. Solution creates Version for every Insert you do . Solution are great when you would like to track each scenario and roll back to previous versions.
Click yes on the above warning and keep adding as many scenarios to the Solution.
Since Solution are created in Master Repository[ SNP_VERSION] , you can find that in other Work Repository.
We are going to extract the scenarios from the Solution created above. To do so , Right click – > Restore All Elements and click yes for the below warnings
Once restored , all the scenarios are imported into the other environment.
Step 5
– create a new Context ‘ XMT_TEST’
[ NOTE : – Make sure you create a new Work Schema for Testing as it will be easy to Testing and Debugging the $ tables ]
step 6
– Creating Data Servers and Physical Schema . [ Being a testing environment i am using the same development source box and so only the target structure is replicated for the newer envrionment, thus creating the new Dataserver and Physical schema and link them to the respective Logical Schema ]
Create the Physical schema and Link the to the already created Logical Schema using the new Context
Keep repeating the same steps for other physical schemas.
Step 7
– Create Agents for the new Testing environment.
Step 8
– Lets test the scenario using the newly created context.
3 Comments
Leave a reply →