BPM: Open Source vs. Red Stack
Schönes Blog Posting von Jakob Freund, warum alle BPM-Interessierten diesen Showdown nicht verpassen sollten…: http://www.bpm-guide.de/2013/05/07/camunda-vs-oracle-roadshow/
OPITZ startet BPM Roadshow im Juni 2013
Mit Business Process Management werden Sie schneller, transparenter, günstiger, … gääähn – alles schon gehört!
Erleben Sie ein nicht ganz alltägliches Event mit OPITZ CONSULTING als Gastgeber für zwei höchst unterschiedliche Protagonisten: Zum einen Camunda, bekannt für die leichtgewichtige, pragmatische und Java-nahe Open-Source-Plattform camunda BPM. Und zum anderen Oracle, mit der hochskalierbaren Oracle BPM Suite als umfassende Lösung für prozessgesteuerte Anwendungen.
Lernen Sie Einsatzgebiete und Nutzenversprechen dieser beiden aktuellen Business-Process-Management-Plattformen kennen. Finden Sie heraus, was zu Ihren Anforderungen am besten passt. Entdecken Sie, wie BPM viele Ihrer akuten Problemstellungen lösen kann.
Diskutieren Sie mit den Fachleuten von Camunda, Oracle und OPITZ CONSULTING darüber, welche Vorteile Open-Source-Lösungen mit sich bringen und was die BPM-Lösung eines führenden Herstellers auszeichnet. Profitieren Sie dabei von den Erfahrungswerten unserer Experten, die aus ihrem Projektalltag berichten und über konkrete, erfolgreich gelöste Herausforderungen sprechen.
Machen Sie sich selbst ein Bild und sehen Sie, wie viel Spaß BPM mit den richtigen Partnern machen kann!
10.06.2013 | Berlin
11.06.2013 | Hamburg
25.06.2013 | Köln
26.06.2013 | Bad Homburg
27.06.2013 | München
Industrial SOA – An article series about service-orientation
Today we would like to point you to a new article series termed as “Industrial SOA” authored by the “Masons of SOA“. The series is dedicated to the exploration of contemporary SOA topics and issues and highlights some of the more recent innovations in practice that will especially be of interest to those who want to learn some techniques that go beyond the academic essentials.
Abstract: “SOA and service-orientation have laid the foundation for a variety of emergent service technology innovations, while the original building blocks of SOA and service-orientation continue to evolve by embracing fundamental service technologies, concepts and practices. These new technology innovations do not replace service-orientation; they use it as their basis. Service-orientation continues to evolve towards a factory approach, towards industrializing integrated platforms, such as BI, master data management (MDM), mobile front-ends, BPM, adaptive processes, Big Data and Cloud Computing – all of which add architectural layers upon SOA-based infrastructure. All of these technologies can interface via standardized data and functions, published as service contracts, in order to avoid redundancy – that’s service-orientation.”
The 14 part series begins with a preface by Oracle veteran Juergen Kress, and then moves on to the first of thirteen articles. The articles are & will be published on OTN and the Service Technology Magazine.
Send your feedback to @twitter/dschmied #industrialSOA.
Automate processes for knowledge workers with Oracle BPM Suite PS6
You introduced BPM in your company? All of your process automations are a huge success? Stop reading – this might be the wrong article for you. Your processes are unpredictable; complex; they keep on changing and they are difficult to model? The users of your software complain that they cannot make proper business decisions because they are forced to certain process steps? Your processes rely on worker knowledge and involve human participants? Good – with Oracle BPM Suite 11.1.1.7 and its new case management functionalities we are now ready to address those requirements. For more information read my article about this hot topic on Inside BPM and SOA.
Purging of failed SOA components
In the previous post the preferred settings of heavily used SOA composites was demonstrated. It was shown that with the correct settings applied only failed component instances are persisted in the database. This post discusses the purging possibilities of such component instances.
As stated in the earlier post, we are now facing a situation where the composite instance itself is not persisted, only its failed component instances. Since the composite is heavily used, even a short outage of a system used by the composite can lead to a huge amount of failures. Having resolved these faults, the need often arises to clear these faults from the system so that fault monitoring is not disturbed by them.
Instances without faults are not persisted in this case because no information from the composite is needed, so a straightforward approach would be to delete the failed instances with Enterprise Manager. In this case, however, this is not possible because the composite instance itself is not persisted and instance purging in Enterprise Manager is based on the composite instance.
Another possibility is to use the database purging scripts supplied by Oracle. These scripts are automatically present in the SOAINFRA schema once the schema is created with the RCU utility. If purging is done with the help of these scripts, the failed orphaned component instances are deleted with the purging run. However, purging generally has fixed time slots and it might be difficult to bring that slot forward if the failed component instances are to be deleted sooner.
The functions used by the purging scripts, however, are also available on their own. A sample script to delete the failed orphaned components could therefore be constructed by using the functions present in the SOAINFRA schema. The same functions can also be found in the scripts which are automatically supplied with every SOA Suite and JDeveloper installation and can be found in the subdirectory rcu/integration/soainfra/oracle/soa_purge under the installation directory.
DECLARE
min_creation_date TIMESTAMP;
max_creation_date TIMESTAMP;
batch_size INTEGER;
retention_period TIMESTAMP;
composite_dn VARCHAR2(125);
soa_partition_name VARCHAR2(10);
composite_name VARCHAR2(100);
composite_revision VARCHAR2(10);
mediator_deleted BOOLEAN;
decision_deleted BOOLEAN;
bpel_deleted BOOLEAN;
fabric_deleted BOOLEAN;
BEGIN
min_creation_date := to_timestamp('2013-01-01','YYYY-MM-DD');
max_creation_date := to_timestamp('2013-03-31','YYYY-MM-DD');
batch_size := 20000;
retention_period := max_creation_date;
soa_partition_name := 'PARTITION';
composite_name := 'TestProcess';
composite_revision := '1.0';
IF soa_partition_name IS NOT NULL THEN
composite_dn := soa_partition_name;
IF composite_name IS NOT NULL THEN
composite_dn := composite_dn || '/' || composite_name;
IF composite_revision IS NOT NULL THEN
composite_dn := composite_dn || '!' || composite_revision;
END IF;
END IF;
END IF;
bpel_deleted := soa_orabpel.deleteNoCompositeIdInstances(
p_min_creation_date => min_creation_date,
p_max_creation_date => max_creation_date,
p_older_than => retention_period,
p_rownum => batch_size,
soa_partition_name => soa_partition_name,
composite_name => composite_name,
composite_revision => composite_revision);
mediator_deleted := soa_mediator.deleteNoCompositeIdInstances(
p_min_creation_date => min_creation_date,
p_max_creation_date => max_creation_date,
p_older_than => retention_period,
p_rownum => batch_size,
composite_dn => composite_dn);
decision_deleted := soa_decision.deleteNoCompositeIdInstances(
p_min_creation_date => min_creation_date,
p_max_creation_date => max_creation_date,
p_older_than => retention_period,
p_rownum => batch_size,
composite_dn => composite_dn);
fabric_deleted := soa_fabric.deleteNoCompositeIdInstances(
min_created_date => min_creation_date,
max_created_date => max_creation_date,
retention_period => retention_period,
batch_size => batch_size,
composite_dn => composite_dn);
IF (bpel_deleted OR mediator_deleted OR decision_deleted OR fabric_deleted) THEN
dbms_output.put_line('Further instances may be present in the system, please rerun the script to delete these');
ELSE
dbms_output.put_line('All orphaned instances deleted');
END IF;
END;
/
This script can be executed in the SOAINFRA schema on demand – even without starting the purging run – thereby assuring fault monitoring efficiency. Keep in mind that while the script is running in the database, performance of the application might be slightly lower because of increased database load. Therefore it is advisable to limit the run time of the script by narrowing the number of processed component instances – either by selecting the composite itself or if that is not possible selecting an appropriate batch size, thereby limiting the number of deleted component instances in one run.
Improve performance and maintenance of heavily used SOA composites
As stated in a previous post, heavily used transient BPEL processes should be configured with some well-defined parameters in order to avoid storing too much data in the database, thus optimizing performance.
However, even if BPEL processes inside the composite are configured this way, data of other components like mediators and the composite itself are all stored in the database. How much information is stored can be influenced by the audit level setting. As of documentation, the audit levels are defined as follows:
- Off: No composite instance tracking and payload tracking information is collected. No more composite instances can be created. No logging is performed. Note that disabling logging and the display of instances in Oracle Enterprise Manager Fusion Middleware Control Console can result in a slight performance increase for processing instances. Instances are created, but are not displayed.
- Development: Enables both composite instance tracking and payload detail tracking. However, this setting may impact performance. This level is useful largely for testing and debugging purposes.
- Production: Composite instance tracking is collected, but the Oracle Mediator service engine does not collect payload details and the BPEL process service engine does not collect payload details for assign activities (payload details for other BPEL activities are collected). This level is optimal for most normal production operations.
Generally, the SOA Infrastructure audit level is set to Production or Development – depending on the environment – and the composites are set to inherit this audit level. In case of an intensively used composite this means that a lot of data is persisted in the database.
The audit level, however, can be overridden for every composite. Since the data from the transient, short-lived composites is not needed, the setting Off for the relevant composite should be an interesting option to consider. Three questions must be answered:
- How much information is persisted from the composite instance?
- How much information is persisted from the component instances inside the composite?
- What happens in case of an error?
Our tests have shown that although the instances successfully complete, no information is stored in the database at all. Neither for the composite instance, nor for any business rule, BPEL or mediator instances inside it. In case of an unhandled error, however, the erroneous component instance is persisted in the database with the details of the error. The composite instance is not saved. This means that the error is seen in the error handling console, it can even be handled if a fault policy is configured, but no information about the corresponding composite instance can be obtained. The composite instance id is set to Unavailable.
We have seen that setting the composite level to Off in case of transient composites causes less data to be stored in the database, thereby increasing performance. The more instances of the composites created per day, the higher the benefit of this approach.
We have also seen, however, that the composites should be well tested before setting this option because it can be quite cumbersome to track the origin of the error. This setting is therefore ideal for a production environment with heavy load, but suboptimal for a development environment with only a handful of instances but the need for extensive testing. This calls for a different setting in each environment.
The audit level setting of a composite can be modified via Enterprise Manager but it can also be defined during deployment, the latter one being more efficient in this case. In order to do so, the following property needs to be added to the composite.xml:
<property name="auditLevel" many="false">Off</property>
The setting here will be treated as the default setting but like many other properties, this setting can be overridden with a deployment plan containing the following:
<composite name="<COMPOSITE_NAME>">
<property name="auditLevel">
<replace>Development</replace>
</property>
…
</composite>
By using deployment plans, the problem of needing different audit level settings in different environments can be easily solved: the audit level of an intensively used transient composite can be set to Off in a production environment whereas the Development setting can be used in a development environment.
OSB 11g: Stuck Threads when using inbound database adapter
Using a polling database adapter in a OSB proxy service, one may have noticed the following behaviour in Weblogic server:
- an exception in the server logs about one or even more stuck threads like this:
<BEA-000337> <[STUCK] ExecuteThread: ’10′ for queue: ‘weblogic.kernel.Default (self-tuning)’ has been busy for “705″ seconds working on the request “weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@21b9db0″, which is more than the configured time (StuckThreadMaxTime) of “600″ seconds. Stack trace:
Thread-118 “[STUCK] ExecuteThread: ’10′ for queue: ‘weblogic.kernel.Default (self-tuning)’” <alive, suspended, waiting, priority=1, DAEMON> {
— Waiting for notification on: oracle.tip.adapter.db.InboundWork@21b8e86[fat lock]
java.lang.Object.wait(Object.java:???)
oracle.tip.adapter.db.InboundWork.run(InboundWork.java:498)
oracle.tip.adapter.db.inbound.InboundWorkWrapper.run(InboundWorkWrapper.java:43)
weblogic.work.ContextWrap.run(ContextWrap.java:39)
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:203)
weblogic.work.ExecuteThread.run(ExecuteThread.java:170)
}>
- and/or server health state from OSB managed server changing from state “Ok” to state “Warning”
Such a behaviour alerts administrators, thinking that something is wrong with the deployed applications or OSB services.
Looking in the Oracle documentation one can find the information that this is behaviour by design and that it can be ignored. To verify the OSB proxy service’s database adapter as the source for this the proxy service has to be simply disabled in OSB console. Doing so makes the stuck threads disappear. The behaviour seems strange at the - so why this?
When defining an inbound database adapter, Weblogic threads are used to perform the polling on events occurring in the defined database. Because OSB is designed to deliver high performance and throughput, a number of threads, which depends on the numberOfThreads property in the adapter’s JCA file, is exclusively reserved for the database adapter to perform the inbound polling. Such reserved threads will, due to performance reasons, never be released and never be returned to the corresponding thread pool. After the configured thread timeout, which is by default about 600 seconds, the stuck thread behaviour occurs.
Although this is the default behaviour, it is really confusing and could lead into serious problems, if real threading problems occur in deployed applications/services that are not caused by the adapter threads and which will not be noticed and handled in time. So what can be done to get rid of the stuck adapter threads?
The Oracle documentation proposes to define a separate Work manager and configure this with the proxy service transport’s dispatch policy. To do so, the following steps has to be performed:
- Define a custom global Work manager using weblogic console with the OSB managed server as deployment target
- Configure the new defined Work manager to ignore stuck threads
- Configure OSB proxy service transport’s dispatch policy to use the new defined Work manager
Afterwards the stuck threads behaviour caused the OSB proxy service or by its configured inbound database adapter should not show up again.
