Experience in using Oracle BAM

Take a look at BIRT. I think of the previous company's use of Oracle BAM. At that time, I started to work on BAM by myself. from scratch, after learning something, I found that Oracle BAM was about to be used for application crash, almost tortured me to death. Without a bunch of bugs, the function design is also quite tasteless. Although it is understandable that it is really difficult to implement real-time without programming Oracle BAM, but it feels that there is a problem with Oracle's design direction. The encapsulation of things is too dead. It takes a lot of time to encapsulate the functions, and there is almost no extension. The advantage is that if you only use the functions provided by it, everything will be done quickly, however, once its functions cannot meet the requirements, it will be finished.

1. Report generation can only be generated directly from DataObject according to the routines provided by BAM. The provided procedures are limited. It is probably a restricted version of the SQL function. Only one DataObject can be operated on. The common problem is that a DataObject is created for a report, and other reports must be generated using the same data, but due to the limited routines provided by BAM, at this time, the data format cannot generate the report we want, and we can only create another DataObject. This results in a large amount of data duplication and complicated integration. One disadvantage of comparing BIRT with BAM is that BIRT can generate a report from the execution result of an SQL statement, so that the SQL statement can pre-convert the data to meet the business requirements. BAM does not have similar functions. Considering that BAM needs to intercept data changes, it is indeed a little difficult to use SQL, but it still hopes to have a similar function.

2. the style of the Report can only be changed in those choices on the page. There is no unified CSS. In this way, if the big boss wants to change the color of all reports, he can only work hard and change the color one by one. At that time, I encountered this problem. Fortunately, it was blocked by TL. Otherwise, I would be exhausted.

3. BAM provides a web-based report editor. The view layout in the report is also made on the web. You can use the cursor to adjust the size and alignment. No tools, no coordinates, no horizontal lines, vertical lines, percentages, or places where values are directly input. There is nothing. If you want to make the page layout look better, then cry. Fortunately, I made a small tool later to export the report. The exported text is actually an XML file. I cut out the report content and Output & lt; & gt; & amp; such characters are replaced by XML escape characters to generate a new xml, directly update the xml content, and you can directly adjust the size, color, and so on. After replacement, the characters are merged into the original XML and then imported into BAM.

4. The dynamic nature is insufficient. There is no place for users to input javascript and other operations on the page. Although BAM generates html, Oracle encapsulates all of these and cannot sneak into javascript. For example, calculator field can also be written in a dynamic language, currently, only the BAM function can be used, making it difficult to perform simple operations on strings.

5. There are too many bugs and the product is not stable enough. The encapsulation is too dead and the consistency of the provided functions is not strong enough. Many of us think that the functions provided by it are not found at the end. before doing anything, we have to do it with our own hands and try it to find out whether it can be done. For example, a Row Group cannot contain another Row Group. The title Font of the Row Group cannot be changed (you can change it with the tool mentioned in 3). The Drill guest SS parameter cannot contain ', '(BAM uses this as the parameter Separator in javascript); Drill guest SS cannot use Calculator field as the parameter.