Seamless source “migration” from SOA Suite 12.1.3 to 12.2.1 using WLST and XSLT by Maarten Smeets

image

When you migrate sources from SOA Suite 12.1.3 to SOA Suite 12.2.1, the only change I’ve seen JDeveloper do to the (SCA and Service Bus) code is updating versions in the pom.xml files from 12.1.3 to 12.2.1 (and some changes to jws and jpr files). Service Bus 12.2.1 has some build difficulties when using Maven. See Oracle Support: “OSB 12.2.1 Maven plugin error, ‘Could not find artifact com.oracle.servicebus:sbar-project-common:pom’ (Doc ID 2100799.1)”. Oracle suggests updating the pom.xml of the project, changing the packaging type from sbar to jar and removing the reference to the parent project. This however will not help you because the created jar file does not have the structure required of Service Bus resources to be imported. To deploy Service Bus with Maven I’ve used the 12.1.3 plugin to create the sbar and a custom WLST file to do the actual deployment of this sbar to a 12.2.1 environment. A similar solution is described here.

Updates to the pom files can easily be automated as part of a build pipeline. This allows you to develop 12.1.3 code and automate the migration to 12.2.1. This can be useful if you want to avoid keeping separate 12.1.3 and 12.2.1 versions of your sources during a gradual migration. You can do bug fixes on the 12.1.3 sources and compile/deploy to production (usually production is the last environment to be upgraded) and use the same pipeline to compile and deploy the same sources (using altered pom files) to a 12.2.1 environment. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Since it provides many components, it is an extensive toolkit for developers who can use it for complex functionality with little coding. by Maarten Smeets

clip_image002

 

Valuable Features:
  • The technology adapters (Database, REST, LDAP, File, many more), which allow easy integration with technologically diverse systems.
  • BPEL and Service Bus, which allow diverse integration patterns to be easily implemented.
  • The extensive Enterprise Manager Fusion Middleware Control which provides management and monitoring capabilities.
  • The high availability features (mostly important for performance and stability).

Since the SOA Suite provides many components, it is an extensive toolkit for a developer, who can, with relatively little coding, quickly achieve complex functionality.

Improvements to My Organization:

We implement SOA Suite at different customers. The product helps them achieve their goals in terms of integration requirements (functional and non-functional). This ranges from service-enabling legacy systems to integrating COTS products in a stable, performant, and manageable way. Currently, I work for a customer that is digitalizing a legal processes. At this customer we implement reusable services and processes used by multiple front- and backend applications. … Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Integration Cloud Service (ICS): A developer’s first impression by Maarten Smeets

clip_image001

 

Oracle provides ICS (Integration Cloud Service) as a simple means for citizen developers to do integrations in the cloud and between cloud and on-premises. On the Oracle Fusion Middleware Partner Community Forum I got a chance to get some hand-on experience with this product in one of the workshops. In this blog post I will describe some of my experiences. I’m not the target audience for this product since I am a technical developer and have different requirements compared to a citizen developer. I’ve not been prejudiced by reading the documentation

I experimented with ICS on two use-cases. I wanted to proxy SOAP and REST requests. For the SOAP request I used a SOA-CS Helloworld web-service and for the REST request I used an Apiary mockservice. I will not go into basics too much such as creating a new Connection and using the Connection in an Integration since you can easily learn about those in other places.

ICS: Calling a SOAP service on SOA-CS

When you want to call a SOAP service which you have exposed on ICS, you require two sets of headers. The WS-Timestamp headers and the WSS-UserName token headers (with the password in plain text).

This is required even when you have not specified a security policy (currently username/password token and basic authentication are supported). When you don’t provide them, you get Service Bus errors (as shown in the screenshot below) which indicates ICS is running on the Service Bus (in case you didn’t know this yet, it is no secret). This was not required when directly calling the SOA-CS service. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Asynchronous interaction in Oracle BPEL and BPM. WS-Addressing and Correlation sets by Maarten Smeets

clip_image002

 

There are different ways to achieve asynchronous interaction in Oracle SOA Suite. In this blog article, I’ll explain some differences between WS-Addressing and using correlation sets (in BPEL but also mostly valid for BPM). I’ll cover topics like how to put the Service Bus between calls, possible integration patterns and technical challenges.

I will also shortly describe recovery options. You can of course depend on the fault management framework. This framework however does not catch for example a BPEL Assign activity gone wrong or a failed transformation. Developer defined error handling can sometimes leave holes if not thoroughly checked. If a process which should have performed a callback, terminates because of unexpected reasons, you might be able to manually perform recovery actions to achieve the same result as when the process was successful. This usually implies manually executing a callback to a calling service. Depending on your choice of implementation for asynchronous interaction, this callback can be easy or hard.

WS-Addressing

The below part describes a WS-Addressing implementation based on BPEL templates. There are alternatives possible (requiring more manual work) such as using the OWSM WS-Addressing policy and explicitly defining a callback port. This has slightly different characteristics (benefits, drawbacks) which can be abstracted from the below description. BPM has similar characteristics but also slightly different templates.

When creating a BPEL process, you get several choices for templates to base a new process on. The Synchronous BPEL template creates a port which contains a reply (output message) in the WSDL. When you want to reply, you can use the ‘Reply’ activity in your BPEL process. The activity is present when opening your BPEL process after generation by the template, but you can use it in other locations, such as for example in exception handlers to reply with a SOAP fault. If you want to call a synchronous service, you only need a single ‘Invoke’ activity.

The output message is not created in the WSDL when using the One Way or Asynchronous templates. Also when sending an asynchronous ‘reply’, you have to use the Invoke activity in your BPEL process instead of the ‘Reply’ activity. One Way BPEL process and Asynchronous BPEL process templates are quite similar. The Asynchronous template creates a callback port and message. The ‘Invoke’ activity to actually do the asynchronous callback is already present in the BPEL process after it has been generated based on the template. The One Way template does not create a callback port in the WSDL and callback invoke in the BPEL process. If you want to call an Asynchronous service and want to do something with an asynchronous callback, you should first use an ‘Invoke’ activity to call the service and then wait with a ‘Receive’ activity for the callback. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Performance by using patterns in service implementations by Maarten Smeets

clip_image001

 

Performance in service oriented environments is often an issue. This is usually caused by a combination of infrastructure, configuration and service efficiency. In this blog article I provide several suggestions to improve performance by using patterns in service implementations. The patterns are described globally since implementations can differ across specific use cases. Also I provide some suggestions on things to consider when implementing such a pattern. They are technology independent however the technology does of course play a role in the implementation options you have. This blog article was inspired by a session at AMIS by Lucas Jellema and additionally flavored by personal experience.
Patterns

Asynchronous services

Suppose a synchronous call is made and the system takes a while to process the information. In the mean time the end-user might be waiting for the processing to be completed while the end-user might not (immediately) be interested in the response. Why not make the process asynchronous?

Making a process asynchronous has some drawbacks. The result of the processing of the request will not be available immediately in the front- and back-end so you cannot use this information yet and often you do not know when (and if) the information will become available. If something goes wrong during processing, who will be informed to take measures? (How) does the back-end inform the front-end when it’s done? You can think of server push mechanisms.

Claim-check

This is of course a famous pattern. The claim-check pattern is often used when large objects are used such as large binary files, which you do not want to pull through your entire middleware layer. Often the data is labelled and saved somewhere. The middleware can get a reference to the data. This reference can be send to the place it needs to be and the data can be fetched and processed there.

Set processing

Service calls are expensive since they often traverse several layers of hard- and software. For example I need to fetch data on a lot of persons and I have a service to fetch me person information. I can call this service for every individual person. This can mean a Service Bus instance, a SOA composite instance, a SOA component instance,a database adapter instance, a database connection and fetching of a single item all the way back (not even talking about hard- and software load-balancers). Every instance and connection (e.g. HTTP, database) takes some time. If you can minimize the instances and connections, you obviously can gain a lot of performance. How to do this is more easy than it might seem. Just fetch more than one person in a single request. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Dramatically reduce SOA Suite 11g startup time by cleaning the MDS by Maarten Smeets

clip_image002

SOA Suite can sometimes be a bit slow to start. This is especially the case when there are a lot of composites to load. Customers using different versions of composites can benefit from undeploying non-default revisions of processes which do not have any running instances (see for example here). Undeployment in most cases is an asynchronous process which does not give feedback. It can partially fail without you noticing (apparently not an atomic transaction). This sometimes leaves composite remains; parts of the composite which are still loaded at startup but are not visible from the Enterprise Manager. Removing these can dramatically reduce server startup time. Especially in an environment which has been used for some time and environments with many versions of composites. Reducing the time required to get the soa-infra application fully up and running is of course mostly relevant for 11g SOA installations and less for 12.1.3 (which does some lazy loading) and 12.2.1 (which supports parallel deployments, also during server start-up).

In this article I’ll demonstrate how these left-over composite parts can be identified and removed on an 11.1.1.7 SOA environment. First try this procedure on a development or test environment before executing it in production! Using this method is entirely at your own risk. Only try it if you understand what you are doing. If something breaks, tell me so I can update this article. Thanks!

Please mind that these actions, although they help with the start time and memory usage of your SOA environment, have less impact on run-time performance than for example purging of instances and reducing the amount of deployed composites (or tweaking datasources, soa-infra database, JVM, etc).

Cleaning

What is a composite in the MDS?

WebLogic Server first brings up its Managed SOA server. After this managed server is up and RUNNING, the soa-infra application is started. After the soa-infra application is started, the composites are loaded from the MDS and put in memory. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Integration Workload Statistics (IWS) on untyped JSON and JavaScript in Composites by Maarten Smeets

 

clip_image001SOA Suite 12.2.1 introduces Integration Workload Statistics. This is a powerful new feature which can be used to do performance measures. Oracle SOA Suite 12.2.1 also introduces untyped JSON support and JavaScript support in composites and Service Bus. What better way to take a good look at both features by doing some performance measures using IWS on composites using untyped JSON and JavaScript!

I created 4 HelloWorld BPEL processes. Two of them are SOAP services and two of them are JSON services (not REST since they do not conform to REST architecture style). Two of these processes contain an assign activity using a JavaScript expression and one of them uses XPATH. I used SOAPUI to fire lots of messages on all services and measured responses. At the same time I had IWS activated to collect data on my processes. The results are quite interesting!

IWS + SOAPUI vs untyped JSON and JavaScript support in SOA Suite 12.2.1

Integration Workload Statistics

Introduction

Integration Workload Statistics provides valuable performance related information on your SOA Suite environment. This ranges from JVM memory usage to duration of BPEL activities. It even provides insight in the functioning of the SOA Suite by providing information on the transfer of messages over composite wires. You can not use it on the integrated WebLogic server provided with the quickstart of JDeveloper though.

Using IWS is simple. First you have to activate it (it’s off by default) by right-clicking the soa-infra application, Monitoring, IWS Reports. Here you can click configure and set the level of detail. After you have applied this setting, you can run reports on the collected data. Report formats supported are CVS, XML and HTML. HTML provides a readable format which also contains some explanation on specific results. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Monitor SOA Suite service response times with Splunk by Maarten Smeets

 

clip_image001Measuring performance of services can be done in various ways. In this blog article I will describe a method of measuring Oracle SOA service response times with Splunk a popular monitoring tool. In order to monitor service response times with Splunk, Splunk needs to obtain its data from somewhere. In this example I’ll use the HTTP access log which I expand with a time-taken field. Disclaimer; my experience with Splunk is something like 2 hours. This might also be an indication of what can quickly be achieved with Splunk with little knowledge.

Making service response times available

log_policy

At first I thought about using the OWSM policy oracle/log_policy. This policy can be applied to an endpoint. The policy logs request and response messages. There is however not (without alteration of the policy) a way to correlate the request with the response message. See the image below. An ECID is logged, but the ECID can differ for a request and response. The ECID can also be the same for different requests in a call chain. Several HTTP or SOAP headers could potentially be used for this, but they have to be present in the request and in the response. This can require some work, especially if you want to add them in the request, since all consumers need to use these headers.

Correlation of request and response messages is not possible OOTB with the log_policy

access.log

The access.log file stores by default some data on HTTP requests such as timestamp, HTTP status code, url and the size of the request. This can easily be expanded with the time which is required to process a request. You can configure this from the WebLogic Console. Go to your server, Logging, HTTP and click the Advanced button. Here you can add time-taken as a field to log in the Extended Logging Format Fields. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

SOA Suite 12.2.1: A first look at end-to-end JSON and JavaScript support in SOA Composites by Maarten Smeets

 

clip_image002SOA Suite 12.2.1 introduces end-to-end JSON support in composites and support for JavaScript in composites. The REST-binding (which can be used by Service Bus, BPEL, BPM) can receive and send untyped JSON without the need to translate it to XML. In BPEL, JavaScript can be used as expression language in various activities and there is a JavaScript embedding activity available.

In this article I’ll show some examples on what you can do with this end-to-end JSON support and give some examples on how to use JavaScript in your BPEL process.

About the implementation

Oracle has used the Mozilla Rhino JavaScript engine which is embedded in Java SE 6 and 7. WebLogic Server 12.2.1 and thus also SOA Suite 12.2.1, runs on Java SE 8 (Java EE 7). Java SE 8 has a new JavaScript engine Nashorn embedded (see here). A possible reason of Oracle for choosing Rhino could be that Nashorn is not thread safe. See here. You can imagine you need thread safety in an environment like SOA Suite.

SOAIncomingRequests_maxThreads is a property indicating the number of threads available to handle incoming requests. It is by default set to the same value as the connection pool size of the SOADataSource. This might not be enough for REST/JSON services. You can find this setting by going to the MBean browser, Configuration MBeans, com.bea, SelfTuning, (domain), MaxThreadsConstraint.

Use untyped JSON

You can use untyped JSON in various BPEL activities such as assign and assert activities. Since the JSON is untyped, you can assign values to elements which do not exist yet and they will be created; there is no message definition. Payload validation will cause a NullPointerException. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

BPM Suite 12c: Oracle Adaptive Case Management: Monitoring Case Events by Maarten Smeets

 

clip_image002Adaptive Case Management (ACM) is an interesting addition to Oracle BPM Suite which has been introduced in 11.1.1.7. Adaptive Case Management is suitable to model complex work-flows in which there is no set order of activities taking place. This allows more control to the end user on what to do when.
When a case is started, it is a running process in the SOA infrastructure. The main component is Oracle Business Rules which governs (among other things) the availability of activities and when certain process milestones are achieved. The case API allows you to query the case events and milestones (how you can expose the API as a service is described here and here by Roger Goossens).
Sometimes people want to obtain information about cases such as;

  • in how many cases has a certain activity been executed?
  • in which cases has a certain milestone been reached?

Cases can crash, be restarted, migrated, aborted, purged, etc. Sometimes you might not want to depend on the running case being there to provide the information you want. Also using the API every time you want certain information might put a serious strain on your system. Using sensors or BAM might help but they require an investment to implement and are still manual implementations with no guarantee you can obtain information in the future you did not think you would need in the present/past.

Publish Case Events
Luckily Oracle has provided the perfect solution for monitoring case events! You can publish case events to the Event Delivery Network (read here 31.17.2 How to Publish Case Events). This can easily be monitored by for example a BPEL process, which can store the information in a custom table. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki