I am trying to learn some more about GitLab CI/CD and wanna write a specific Stage like "wrap_packages", where a specific list of .sql-Files is given and these scripts should be wrapped to .plb, to copy&paste them into a specific folder.
Everything is working so far, but now i have to implement the wrapping. I guess i have to use an image, with Oracle Middleware, to use the wrap-command? Or is there a better way to do this? Because i cant find anything that helps me with this.
I hope you can help me with this.
The wrap utility either exists in the full OCI client installation (not instant client), or within the actual database as an API. The simplest way to wrap your code is using the database API, after it is installed, as demonstrated here: https://github.com/pmdba/code-obfuscation-toolkit. There are a variety of ways that this could be incorporated into your CI/CD pipeline.
If you're looking for a more robust commercial (licensed $$$) solution, consider PCFLObfuscate (http://www.petefinnigan.com/products/pfclobfuscate.htm). It has a command-line option that integrates well with CI/CD.
A question that must also be asked is why you want to obfuscate your code with "wrap"? At best obfuscation only slows down someone who wants to see your code, as it is rather easily undone (at least the wrapping part). Deeper obfuscation (as provided by PFCLObfuscate, for example) actually changes the formatting of your code, your variable names, etc. before wrapping to make it much harder to tell what is going on even after it is unwrapped.
It is important to understand that there is no level of protection available for PL/SQL that can prevent someone with access to the wrapped code from unwrapping it and seeing the actual PL/SQL.
Related
I have been using Karate for the past 6 months, I am really impressed with the features it offers.
I know karate is meant to test API(s) individually but we are also trying to use it for E2E tests that involves calling multiple scenarios step by step.
Our feature file looks like below
1.Call Feature1:Scenario1
2.Call Feature2:Scenario2
.....
Note: We are re-using a scenarios for both API Testing and E2E testing.Sometimes I find it difficult to remember all feature files.
Can we chain the scenario call like java, I doubt feature file will let us to do that. We need your valuable suggestion. pls let us know if you feel our approach is not correct
First, I'd like to quote the documentation: https://github.com/intuit/karate#script-structure
Variables set using def in the Background will be re-set before every Scenario. If you are looking for a way to do something only once per Feature, take a look at callonce. On the other hand, if you are expecting a variable in the Background to be modified by one Scenario so that later ones can see the updated value - that is not how you should think of them, and you should combine your 'flow' into one Scenario. Keep in mind that you should be able to comment-out a Scenario or skip some via tags without impacting any others. Note that the parallel runner will run Scenario-s in parallel, which means they can run in any order.
So by default, I actually recommend teams to have Scenario-s with multiple API calls within them. There is nothing wrong with that, and I really don't understand why some folks assume that you should have a Scenario for every GET or POST etc. I thought the "hello world" example would have made that clear, but evidently not.
If you have multiple Scenario-s in a Feature just run the feature, and all Scenario-s will be executed or "chained". So what's the problem ?
I think you need to change some of your assumptions. Karate is designed for integration testing. If you really need to have a separate set of tests that test one API at a time, please create separate feature files. The whole point of Karate is that there is so little code needed - that code-duplication is perfectly ok.
Let me point you to this article by Google. For test-automation, you should NOT be trying to re-use things all over the place. It does more harm than good.
For a great example of what happens when you try to apply "too much re-use" in Karate, see this: https://stackoverflow.com/a/54126724/143475
Is there something similar to a standard library for modern ABAP (maybe even OO-Abap)? For example a curated list of objects that address some of the most common programming tasks like
high-level data structures (not just plain internal tables)
working with file paths and directories
working with files (reading, saving, ...)
working with different file types (text, csv, xml, ...)
regular expressions
working with the environment (client, application server)
...
My current workflow is to stumble upon a problem like getting the extension of a file from a filename (or something fairly similar and easy). Then I have three options:
Dig through a ton of (mostly old and lacking) posts on SDN until i maybe find a pointer to solve the problem
Hack away and create a one-off solution to the problem
Take my time and implement a good and well documented solution
Many times I feel a bit lost. A lot of the available information is old, bad or both. Is there a more structured approach to tackle the problem of finding a suitable abstraction in the ABAP-world?
To answer your first question no, unlike C, C#, Java, there is no need to include a library since all the functions are always available to you, so in that regards it might be simpler. What you are asking though is a great question, I am sure you probably see tons of queries in SDN for "Is there a Function module for?" etc.
There isn't an easy answer but In SAP ABAP I think the easiest way might be to find this is by looking at packages. Similar to a library by looking at a package for the type of function your looking for might get you there. For example if I am looking for handling files I might look for the control framework package and there I can see all the available functions/classes/methods/BAPIs etc. that are related to front end controls/file handling etc. and might be able to find what I am looking for. Note its not perfect as the way packages are used has changed from time to time so its actually better for finding functions related to for example purchasing or sales etc. but its one way that we use.
Like other languages in that we still need to know what library to link in to get the function you need, in ABAP you just have to find the related package. Hope it helps a little, I know its not perfect. Example package for front end controls
For working with the environment:
If you have access to SAP there is a transaction code called BAPI
Here you could find a hierarchical list of all the main objects in SAP (i.e. Material, Purchase Order, etc)
In this list you could find documentation, the function modules used for the object (i.e. créate/get detail/update etc)
And digging into the function modules could take a look to the structures, receiving parameters, etc
The other questions are a little bit complex, I am not aware of any comprehensive list but digging into SCN usually is easy to find a solution for the most common things like handling files, etc
In the particular case of regular expressions, SAP native language, ABAP, has keywords for handling them, but you also have a class in SAP called CL_JAVA_SCRIPT which you could use for doing thigs in "JavaScript way"
For example I used this class in the past to evaluate a simple formula provided in a string (i.e 3 + 2 * 5 )
This is an operation really complex to do in ABAP but easy to do in JS.
Hope it helps
SAP Reuse Library (SE83) is the most close thing to what you are looking for. It provides common development tasks grouped in hierarchy (UI controls, standard dialogs, confirmation prompts) and contains code snippets for each with commonly used classes/modules:
Though, it is incomplete and lacks many popular things.
Consider also DWDM, BIBS, LIBS transactions and other packages in this link.
We are interested in using Odoo but we would need to modify it slightly for our use case, for instance modifying partner by adding fields, and integrating with an external system.
Is it best to fork it or to make a module with the changes in? The changes would be quite specific to our use case and existing system so it's unlikely it would be useful to anyone else as a module/app.
My thinking is that by forking it would be easier to stay up to date with Odoo - we just have to pull in changes from upstream occasionally. It seems like with a module you would end up with lots of stale code that's difficult to update because you've moved it outside the source tree.
It also seems like it would be easier to deploy because you have all the code in one place rather than two.
As from my POV and according to many years of ERP - experience, it is the best advice to implement those kind of changes always in an own module (inheriting all the required standard components) and leave the standard untouched. This applies also for very specific customizations as well as for general improvements.
This procedure provides you with the best flexibility in installing, updating, distributing and maintaining your code while not being touched when updates to the standard modules are carried out on the target systems.
You will also be able to share and move your code between dev/test/prod systems and applying a version control on it.
Please always make sure to be in line with valid license obligations applying to your code (especially when inheriting standard modules).
Hope this helps ;-)
Due to some constraints on our production code, we have some .NET services that need to be run with their own config file. We've been using app-domains to provide arbitrary config files to these services at test run time.
The problem comes when we try and use SpecFlow for these tests - since each step is called separately and from an overall runner class that we don't have direct access to, pushing test data across app-domain boundaries for every single STEP is pretty messy and results in everything being in all sorts of odd lambdas, plus serializability needs to be considered when most of the time we shouldn't need to care about that in a test code context (internal data objects, that sort of thing).
Does anyone have a method by which SpecFlow can be convinced to run all of its steps in a provided app-domain, or generally just play nicer with the app-domain concept in general?
Would it be possible to write a plugin / test generator that did this, and if so would this be very technically complicated? I had a look at that sort of extensibility but couldn't find the right place to start to do this, so I may have missed it.
(I'm aware that "Refactor your service so you don't need arbitrary config files" would also solve the underlying problem, but for the purposes of this question please assume I can't do that - I'm interested in whether SpecFlow can be configured to solve this, whether on its own or by extending it.)
Edit: After some more investigation I think this -should- be possible by using a custom unit test generator plugin? The problem I then have is there's basically zero documentation on that, and not many examples around on the internet. If you can give me a good example that I can look at to adapt that would go a long way...
I'm trying to figure out a good practice approach of when I should use Background over a Before hook.
I've browsed around the web looking at other peoples blog post but there's so much over lap.
Any opinions when to use which, and perhaps more importantly, when definitely not to use one of them?
My take on differentiating between the two comes down to using the tests as communication. If the functionality that you're adding is necessary for anyone reading the plain language Scenarios and features, it should go in the Background section. If the functionality is simply part of the implementation of your test framework, it should go into a Before hook.
Keeping the scenarios and features clear is an important part of building good Cucumber tests.
I guess another mental check you could use would be to ask yourself if someone was testing your scenarios manually, would they need to do the functionality that you want to put in the Background/before hook. If they would, I'd put it in the Background section in the feature file. If they wouldn't, put it in the hook back in your code.