Friday Dec 02, 2011

Easy Automation of common Weblogic and FMW Administration commands via WLST Recording

The WebLogic Scripting Tool (WLST) is a command-line scripting environment that you can use to create, manage, and monitor WebLogic Server domains. Weblogic Server provides you a way to record your configuration edits in the WLS Console as WLST scripts that can then later be edited and used for configuration automation. Note that for security reasons, it does not allow you to record all commands. Refer to the Weblogic Server documentation for what is disallowed.

Here is a simple run through of how you can use WLST recording and generate scripts for config automation. In this example, we will record the creation of a simple JDBC resource via WLS Console and edit it post-recording.

Step 1: Log into WLS Admin Console and click on “Preferences” at the top and click on the “WLST Script Recording” tab.

This page gives you details on where the script will be generated post recording, and the name of the file. You can change it to suite your needs.

Step 2: Click on “Start Recording” and then proceed to create the data source as shown in the steps later. This is under the assumption that Automatic Recording is turned off. In this case, you can start and stop recording when you have finished atomic recording tasks. Once you start recording, you can see a message indicating that the recording is on.


Step 4:Once you have completed the configuration, you can click on “Preferences” at the top to come back to the Recording settings page and stop the recording. You can see that the recording window has captured all configuration changes in Jython format.

Step 5: Click on “Stop recording” to generate the file at the desired location.



Step 6: Next, you can update the script to pass them as command line arguments or read them from a property file. See below.

Step 7: WLST can be run in a variety of ways. One way is to set the environment using wlserver_10.3/server/bin/setWLSEnv.sh and then running

java Weblogic.WLST scriptName.py.

Refer to the WLST documention for other means to execute WLST [Interactive, Embedded, Ant etc].

Friday Sep 16, 2011

When Java Meets SOA

Overview

Typical composite applications involve integration amongst a variety of source and target systems, including but not limited to messaging systems such as AQ or MQ Series, Applications such as e-Business Suite or Siebel, Databases, Custom applications, B2B partners etc. Oracle SOA Suite 11g provides connectivity to variety of such sources, and at the same time, enables users to model complex business processes orchestrating messages amongst these systems in an Agile fashion.

Java incarnates at several points within most of these integration projects. They could manifest as existing Java Assets that you may need to converse with – such as EJBs or POJOs, as utility components that you need to callout to process complex financial algorithms, or as assets that you yourself need to build during the integration to handle business or system errors.

It is imperative to understand the different options in hand while designing integrations with Java or J2EE components. You will be able to leverage the full potential of each option by exercising them where they are a good fit, while understand the pros and cons that come with it. This weblog entry discusses these options in greater detail. Also discussed are various options to invoke SOA Suite composites via Java.

Integrating with Java or J2EE Components

Here are a few options that you may consider while integrating with Java components.

1. Java Embedding

When to use:

Java embeddings are extremely useful while building small utility snippets inline within BPEL
processes. This includes like regular expression processing, String manipulation, Mathematical computations, invoking Java APIs to perform tasks on the file system such as run windows tasks or execute batch scripts etc.

Product Support:

Java Embedding is a BPEL feature.

Pros:

1) Provides inline access to Composite and component information, and also BPEL variables.

2) Can add entries to BPEL audit trails from within the embedding.

3) Façade APIs available for easy DOM Manipulation.

Cons:

1) Since Java embeddings are inline java code, they are inherently non-reusable. If you plan to re-use the embedded functionality, java embedding may not be a great idea.

Notes:

1) Do not use to build complex Business Logic

2) Limit the amount of code within your embedding to avoid code maintenance and management overheads.

2) If invoking transactional endpoints, the transaction is propagated into the target endpoint.

3) Do not use Java Embedding to converse with the target systems of your integration. This will reduce the visibility within your Enterprise Application and is considered a poor design.

4) Exceptions can be thrown and treated as BPEL Faults.

More Information:

Oracle SOA Suite Developer’s Guide

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_java.htm#BABFCJDJ

2. Custom BPEL/XSLT XPath Functions

When to use:

1) You can wrap your Java objects into XSLT or BPEL XPath extension functions when you wish to leverage them within your data assignments, conditions, or XSL Mappings. Most of these use-cases involve Java components that perform mathematical computations, String manipulation etc, just like the Java Embedding does.

Product Support

XSLT XPath functions can be used within any XSLT within SOA Suite or OSB. Evidently, BPEL XPath functions can be referred to only within BPEL processes.

Pros

1) Stateless Utility Code can be converted into an XSL XPath function without any additional coding.

2) Promotes code re-use.

Cons:

1) If you have existing java components, you may need to build wrapper objects that implement a specific BPEL Interface for them to be used as BPEL XPath extension functions.

2) No security features are available when Java components are exposed via XPath functions.

Notes

1) Do not use to build complex Business Logic.

2) Do not invoke target systems that you are integrating from within your XPath functions, since you will lose visibility. This is generally a bad modeling approach.

More Information:

Oracle SOA Suite Developer’s Guide

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_appx_functs.htm#BEIIAHJH

3) JAX-WS or JAX-RPC Web Services exposed using SOAP/HTTP

When to use:

One of the most widely used deployments for Java components. Typically used when you need to expose java assets as discrete Web Services, especially across firewalls - an important use-case for SOAP.

Product Support:

SOA Suite

Pros:

1) The Web Service can be managed and maintained separate from the Business Process or the Integration.

2) Allows for clean contract based conversations since the Service is based of the WSDL.

3) Can be registered in a Registry/Repository

4) Can be virtualized using a Service Bus.

5) Can be re-implemented in any platform or programming language without impacting the calling services.

6) Can be secured, monitored and tuned from the infrastructure level.

Cons:

1) Object2XML conversions and SOAP add additional overhead.

2) Not a great choice if you need transactionality

3) Needs personnel who understand JAX-WS stack to build, develop and maintain the services.

4) Requires client applications that can communicate via HTTP.

Notes:

1) JAX-WS allows for Async conversations too.

4. EJB Services

When to use:

1) When you wish to communicate with EJBs via a) SDO parameters [WSDL Based], or b) Java Interfaces [no WSDL].

Product Support:

SOA Suite

Pros:

1) Native Java/RMI calls avoid additional overhead introduced by SOAP.

2) When EJB Service w/Java Interface is called from Spring components, avoids O2X conversion costs

Notes:

1) Users may need to be well versed with ORM and persistence technologies.

More Information:

Oracle SOA Suite Developer’s Guide

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_sdo_ejb.htm#BAJBCFGE

5. Spring Component

When to use:

1) When you want to expose your Java Components as First Class Citizens in your SOA - allowing it to converse and exchange messages with other Service components and SCA References. Thus useful when your Service component needs to perform Java Processing as well as need to invoke a Mediator, BPEL, EJB or another Web Service.

2) Useful if you have existing assets such as Spring/Hibernate Applications that you want to bring into your SOA.

3) Useful while migrating from JCAPS to SOA Suite to wrap JCDs into Spring Beans.

4) Also useful while migrating from WLI to SOA Suite for Custom Controls.

5) Do not use as a replacement for other built-in components such as BPEL, Mediator or Adapter Services.

Product Support:

SOA Suite

Pros:

1) Re-use of existing Assets

2) Enables use of Aspect oriented programming declaratively within your POJOs.

3) Enables Auditing of your Spring components via EM [Feature not available yet]

4) Can be secured via OWSM policies.

5) Being a native service component, easily integrates with other SCA Service and binding components."

Notes:

1) Can be exposed as a SOAP/HTTP Web Service, or as an EJB.

2) The Java classes are packaged within the Composite archive itself."

More Information:

Oracle SOA Suite Developer’s Guide

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_spring.htm#BCGCJGDF

6. Java Callouts

When to use:

1) Useful to implement Prologue and Epilogue style invocations to java code before and after execution of routing rules in mediator.

2) Useful to cleanse input/output XML payloads, or perform context specific logging.

Product Support

This is a Mediator feature.

Pros:

1) If you have existing Java Assets that manipulate XML payloads before sending out to partner applications, then you can directly re-use them within your Mediator Java Callouts, as a faster alternative to building new XSLT maps.

Cons

1) No Auditing/Visiblity into the Callouts

Notes:

1) Need to implement a specific Pre-defined Interface.

2) The Flow trail indicates a preRoutingRule or a postRoutingRule being invoked.

More Information:

Oracle SOA Suite Developer’s Guide

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/med_createrr.htm#BGBDBHBE

7. OSB Java Callouts

When to use:

1) Useful if you need custom validation/transformation/security, or message enrichment in your Bus pipelines.

2) Use is preferable on inbound side.

3) Use a custom transport instead of a Java Callout on the outbound side.

Product Support

This is an OSB feature.

Notes:

1) Simple interface to invoke Java methods within a JAR resource.

2) Automatic type conversion for parameters and return value.

3) Integrated lifecycle management of SOA and Java (jar) resource.

4) Users can view the POJO/Parameters from OSB Console/Design-time.

6) Use EJBs as Java Callout targets when you need better management while accessing XA resources. However, POJOs also allow propagation of transaction and security context.

7) POJO Must be thread-safe.

More Information:

OSB User Guide:

http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/pojo.html

8. OSB EJB Transport

When to Use:

       1) Primarily to integrate with existing or new EJB assets, and provide transport mediation security, monitoring and alerting features etc of OSB.

Product Support

This is an OSB Feature.

Pros:

       1) Since EJB Transport provides JAX-RPC mapping, it is useful when you wish to expose EJBs as SOAP/HTTP web service, or REST endpoints that speak XML.

Cons:

       1) EJB Transport is an “Outbound-only” feature. You cannot expose a Service as an EJB via this feature.

9. OSB JEJB Transport

When to use:

       1) Very useful for native java integration. Typical use-case would be when your client and service are both Java Applications.

Product Support

This is an OSB feature.

Pros:

       1) Fully embraces XA and security semantics

       2) Supports inbound and outbound interactions, as opposed to the EJB transport, that supports only inbound.

Cons:

      1) Does not support Java2XML conversions.

Notes:

      1) Both EJB 3.0 and 2.1 supported.

10. JMS Transport

When to use:

      1) Use-cases are similar to the OSB JEJB Transport – native java integration. You could typically receive java objects onto the bus from a JMS Topic [JMS MessageType = ObjectMessage] transport and then invoke a Java Callout that can directly process these objects sans any conversations. Alternatively, you could drop an JMS Object Message onto a JMS Topic using this feature.

Product Support

This is an OSB feature

Invoking SOA Suite from Java Components

1) Locator API

For you to use the Locator API, ensure that you have an ADF binding (binding.adf) on your Service Interface. The Locator API is very similar to what you have seen in SOA Suite 10g.

Hashtable props = new Hashtable();

props.put(Context.PROVIDER_URL, "t3://adc4100101a:7001/soa-infra");

props.put(Context.INITIAL_CONTEXT_FACTORY,

"weblogic.jndi.WLInitialContextFactory");

props.put(Context.SECURITY_PRINCIPAL, "weblogic");

props.put(Context.SECURITY_CREDENTIALS, "weblogic1");

Locator locator = LocatorFactory.createLocator(props);

Composite composite=  locator.lookupComposite("default/SimpleApproval!1.0");
Service service = composite.getService("simpleapprovalclient");
String msg = “<input><msg>Hello World</msg></input>";
NormalizedMessage req = new NormalizedMessageImpl();
req.getPayload().put("payload", msg);
NormalizedMessage responseMsg = service.request("execute", msg);
Element respPL = (Element) responseMsg.getPayload().get("payload");
 

More Information:

Oracle Fusion Middleware Infrastructure Management Java API Reference for Oracle SOA Suite

http://download.oracle.com/docs/cd/E14571_01/apirefs.1111/e10659/toc.htm

2)  Direct Binding API 

Originally used for connectivity between SOA Suite and OSB. The API also leverages the Locator API, but has slight differences from the former. The developer’s guide has very good examples illustrating how java clients can use Direct Binding API to invoke SOA Composites. See link below.

More Information:

Oracle SOA Suite 11g Developer’s Guide http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/invocapi.htm#CHDBBBBC

3) Java Web Services Proxy

You can generate a Java Web Services Proxy [JAX WS or JAX-RPC] from within JDeveloper and invoke the SOA Composite using SOAP/HTTP. Note that if the SOA Web Service is secured via message level security or TLS, the proxy should be updated to provide the credentials as appropriate.

Refer to JDeveloper documentation for more information.

4) Adapter Interface

Java components may interface with SOA composites via file system, database tables, JMS Destinations etc. The Java client may drop a file into a directory on the file system, or enqueue messages into a JMS topic that is being polled by SOA composites (through Adapters) that could then pick up the message and continue processing.

Other Meeting points for Java and SOA Suite

1. Fault Handlers

You can configure to use a Java Action within your Fault policies. These Java based Fault Handlers need to implement a specific Interface. [Separate ones for BPEL and Mediator].In both cases, you have access to the in-scope messages/variables for query/update.

See section 21.1.1.2 of SOA Suite Developer’s Guide for details on Mediator Java Fault Handler.

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/med_faulthandling.htm#BABGFBCB

See section 11.4.3 of SOA Suite Developer’s Guide for details of BPEL Java Fault Handler.

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_faults.htm#BABJIBJB

2. Sensor Actions

You can configure the Publish target of a Sensor Action to be a custom Java Class. You need to implement a specific Data Publisher interface to be able to register as a sensorAction target. See section 17.2.5 of the SOA Suite Developer’s Guide to see how.

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_sensors.htm#BABEBIFB

3. Custom Workflow Clients

You can implement the Workflow Java APIs to build a custom Worklist client.

See Section 30.3 of the SOA Suite Developer’s Guide for more information.

http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_worklistcust.htm#CIHJAHBJ

Wednesday Sep 14, 2011

Spring Framework Samples

You can leverage Spring Framework to integrate components that use Java interfaces into SOA composite applications. Oracle SOA Suite uses the spring framework functionality provided by the WebLogic Service Component Architecture (SCA) of Oracle WebLogic Server. In this weblog entry, you can find a few Spring Component samples that you may find useful. Each of the given sample contains a README that provides step-by-step instructions for developing and testing the Composite, along with a complete JDeveloper project that you can deploy and test directly. More samples will be made available soon. Please provide feedback on what specific features you would like to see within upcoming Spring samples.

1) Hello World - A simple composite with a Hello World style Spring Component

2) Spring calling BPEL - Sample illustrating how you can call a BPEL Process from Spring.

3) Spring AOP - Sample illustrating how you can use dynamic proxies to achieve AOP with Spring.

4) Predefined Spring Beans - Sample illustrating how you can use the predefined beans within SOA Suite to process headers, access composite information, or just perform context-aware logging.

5) Global Spring Beans - Sample illustrating how you can expose a simple POJO as a global spring bean that you can access within any SOA composite.

Wednesday Apr 06, 2011

Oracle SOA Suite and BPM Suite VM [Oracle Virtual Box]

Just in case you missed to notice, you do have this all-in-one Box that runs SOA Suite, BPM Suite, B2B and BAM, right on OTN.
Click here for the download link.

Take a look at this entry in Antony Reynold's blog for getting started on this.

Enjoy!

 

 

About

Principal Product Manager

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today