Let’s start with versioning. Isn’t that simple? Just commit your code or check it out. Well first question is: how do I get my code out of Oracle Data Integrator and how am I sure the integrity is respected?
Same for the restore: how do I get this out of my versioning system and how do I get it correctly into my ODI repository? In a first release our versioning component solved this as follows.
To start you need to enter the ODI, Master and Work Repository info and the connection details for Subversion. We mapped the ODI Repository structure to Subversion and had Projects, Models, Scenarios and load plans, Global Objects, Topology. For each object we created an separate XML file and a related shadow XML file to manage the dependencies.
From here, you could commit. Objects and object dependencies were stored. The restore operations allowed you to just restore the objects without the dependencies or with the dependencies. You could also lock and unlock objects to prevent other users to make changes. All worked fine.
The VCR4ODI application was simple to install, just launch and there you go. To start you need to enter the ODI, Master and Work Repository info and the connection details for Subversion.
So far so good. But once you start having customers, good questions come up.
One of our customers, by example said they were using LDAP to connect to their ODI Repositories. So we had to add support for LDAP. Seems easy once you have figured out everything. Then some started to use the product heavily and had performance questions. Which lead to improving performance but also extra functionality.
Some other examples of questions that came from prospects and customers:
- Can you remove Topology from the dependency validation and exclude it when checking in and restoring objects?
- Can we commit selectively: just the objects, not the dependencies?
- Can we handle deleted Objects in ODI so that ODI and SVN do not get out of sync and they can be deployed later through the test and production environments ?
- Can you handle renamed objects (see delete)?
- Can we also handle database scripts?
- Can you add role based access and security?
So what are the lessons learned here
At first glance versioning and restoring ODI looks simple. But coming out of the lab and facing reality a lot of good questions come up. Only by listening to customers and prospects you get the right requirements. Only by that listening and doing what they ask you get your product right. Did we already implement all requested features ? No, but most of them yes.
And we continue to implement them and we love to hear your comments, remarks.
About the author
Hello, my name is René De Vleeschauwer.
Throughout my career I've been responsible for the development of enterprise software. Since 12 years I've been leading the development of IKAN ALM, an open DevOps framework.
Do you have any questions about this post? Just ask me!