Check Composite State of Oracle SOA Suite by Command Line by Dirk Nachbar

image 

I was currently fighting a bit with the monitoring of Oracle SOA Suite 12c Composites.
The goal was to check the state of deployed Composites on an Oracle SOA Suite 12c with following requirements/dependencies:

  • No Oracle Cloud Control
  • Capture only Active Composites and not Retired Composites

After some discussions with colleagues and a lot of Google and serveral tests with Python Scripts in wlst, I came to following solution:

  • one main Pythin Script, called check_composite_state.py which is checking the State of a non retired given Composite Name for a given Partition|Folder and a given Managed Server
  • one property file called domain.properties which will be used by the Python Script in order to build the required connect string to the Admin Server of the SOA Suite
  • one wrapper Shell Script, which takes the required 3 Arguments (Name of Managed Server, Composite Name and Partition|Folder Name). Read the complete article here.

Jump-Start your Oracle SOA Projects in FlexDeploy by Dan Reynebeau

image

In an effort to simplify the population of existing composites on a server into FlexDeploy projects, we have provided a utility to extract composites from a SOA server into a comma delimited file. This file can then be the basis for a spreadsheet that can be loaded directly into FlexDeploy, through the use of templates, and all of the composite projects can be created in seconds. I will talk about templates in another blog post.

The composite extraction from a SOA server can be done with the attached zip file (extractComposites).  There are three components in the zip file:

  • Property file that contains the userName, password, hostName and hostPort for the targeted SOA server
  1. #Weblogic server username and password
  2. server.user=weblogic
  3. server.password=welcome1
  4. #server.host=
  5. server.host=soalt06.flexagon
  6. #server.port=
  7. server.port=8001
  • CompositeMgmt.jar that contains the code that interrogates the targeted server
  • ExtractComposites.sh that contains the script that manages the jvm and classpath

Read the complete article here.

Avoiding Service Call Failures in Oracle Service Bus and Oracle SOA Suite by Rolando Carrasco

image

Introduction

This article is targeted at Oracle Service Bus (OSB) developers and architects who want to learn/validate their strategies for avoiding service call failures within their integration pipelines.

Having dual roles as architects and developers the authors have seen many projects in which the developer or the architect didn’t design or implement a good exception/failure management strategy.

This article will streamline a series of strategies to avoid such failures.

Some of the ideas in this article are were originally presented by our colleague David Hernández in a December 2015 session at a Microservices and API Management Symposium in Lima, Peru. That session focused on various strategies for mitigating failures in the development of Services:

  1. Circuit breakers
  2. Bulkheads
  3. Timeouts
  4. Redundancy

In this article we will apply these strategies to Oracle Service Bus.

These strategies can be implemented using OSB and Oracle SOA Suite (composites). Some features of the current latest release (12.2.1) will help you to facilitate the implementation; other strategies are very basic configurations in OSB that many people skip and therefore struggle to maintain stability in their Service Bus implementation.

Let’s always keep in mind that the Service Bus is a core element in any infrastructure that implements it. CIOs and managers sometimes do not give that specific weight to this platform and wonder why, if the OSB/SOA Suite is not available, the infrastructure crashes. Or sometimes they wonder why the OSB struggles when a platform is not available or is under heavy load. The answer is simple: OSB is the integration pipeline within your infrastructure and architecture. Imagine if a water pipeline in your house breaks: you don’t see it, but a real mess is happening behind your walls or beneath the floor. The same idea applies here.

Let’s also bear in mind that 60% of the development of a service is related to exception management and the ability to avoid failures. If we don’t take care of this, or expect that someone else will take care of it, we are wrong. You need to be able to identify the following scenarios: Read the complete article here.

Purging Strategies in Oracle SOA Suite 12c – Part II by Arturo Viveros

image

In my earlier post about purging the Oracle SOA product database, I mentioned that this is one of the most critical tasks when it comes to ensuring the stability and performance of SOA/BPM Suite production environments.

Read the 1st part here

This means that you should never neglect this or expect it to magically take care of itself.

So let’s take a look at a couple of extra tips to get a better grip on this:

In 12c we have auto-purge, which can be configured and scheduled from the EM console. Unfortunately, EM still lacks a reporting / alerting feature to provide purging statistics or at least make sure the jobs are actually running successfully. So, if you’re blindly trusting this feature, it could very well be that instances are piling up by the millions without you noticing until it becomes a problem.

Luckily, there’s a very simple way to find out and keep track, just by looking into the SOA_PURGE_HISTORY table inside the SOAINFRA schema:

This table is pretty straightforward, as it will tell us the start & end time, if it was the single or the parallel script and the final status: C (Completed) or R (Rollbacked).

The out-of-the-box scripts are quite sensitive and enforce a lot of validations, which means that if anything goes wrong they will rollback everything and no instances will be purged whatsoever. So in case there’s a malfunction it’s good to be able to know and take the necessary steps to correct it before everything blows up. Read the complete article here.

FAQ: Integrating E-Business Suite using Integration Cloud Service by Naveen Nahata

image 

1. Is the connectivity agent necessary for the EBS Adapter even when my services are deployed inside DMZ and publically accessible.

No. The connectivity agent is only required when EBS REST services are not available on public internet.

2. Can I connect to EBS database from ICS and invoke PL/SQL procedures?

Yes, you can use DB adapter. However, JDBC connections are not allowed by ICS so the connectivity agent is required to connect to EBS database

3. Is it required for the connectivity agent to be accessible from ICS?

No. ICS does not call the connectivity agent. Instead the connectivity agent calls ICS. Since it is a HTTPS call over port 443, most organizations do not restrict it.

4. Our organization requires a proxy to connect to internet. How do I handle it?

The connectivity agent allows the use of proxy. You can provide proxy details such as proxy host/port and optional username/password as parameters to the startup script.

-ph=<PROXY_HOST> -pp=<PROXY_PORT> -pu=<PROXY_USERNAME> -ppw=<PROXY_PASSWORD>

5. How does ICS invoke EBS web services or PL/SQL procedures when it can connect to neither the database/web server nor the connectivity agent.

Whenever ICS needs to communicate with EBS or its database, it posts a message in a queue. Connectivity agent periodically polls this queue and retrieves the messages. It then invokes EBS web services or makes a database call.

6. I’ve created an integration which is triggered on an EBS Business Event. How does connectivity agent handle this?

The connectivity agent is only required during the intial activation of the integration. Once the integration is activated, its endpoint is registered with EBS Workflow Business Event System. EBS directly invokes ICS integration when the event fires.

You can check this by opening the Business Event and looking at the subscription ICS creates. Read the complete article here.

Custom functions to extend ICS transformations – ICS Definitive Guide by Robert van Mölken

image

In the second release of 2017 (17.2.5) ICS will introduce the capability of importing and using custom functions. These functions are created using JavaScript and can be used in transformations, expressions and as a action in Orchestrations. In this definitive guide I will go through all ins and outs of this new capability.

Custom functions – a new pillar of ICS

In our book we talked about the pillars of ICS; Connections, Integrations, Lookups, Agents, Adapters and Packages. This release introduced Libraries. A library is a set of Javascript functions. Keep in mind that the JavaScript functions are running server-side so some browser/client-side capabilities/APIs are not available. Functions can’t be created within ICS, but can be uploaded as part of a library in both JS and JAR file (collection of JS files) formats.

For this guide we have created two library files; string-utils and date-utils. The string-utils library contains seven functions and the date-utils library contains only two functions. Below is the contents of the latter library, where the first function calculates the duration between to two dates by returning a dayTimeDuration string as result. The second function is used for parsing ISO dates since the javascript engine ICS uses does not support ISO date when creating new Dates in javascript. Read the complete article here.

 

ICS roles by Niall Commiskey

image

I get quite a lot of questions about the user roles available in ICS. Some of the questions relate to user access to data. For example, how do I prevent developers seeing payload values, such as credit card number.
The starting place for eliciting such information should be the ORCL docs – here I read

Read the complete article here.

Top tweets SOA Partner Community – April 2018

image

April 2018  top tweets by soaCommunity

Send your tweets @soacommunity #PaaSCommunity and follow us at http://twitter.com/soacommunity. Make sure you share your content with the community!

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

Technorati Tags: twitter,SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress,SOA Community twitter

Oracle Mobile Cloud Service (MCS) and Integration Cloud Service (ICS): How secure is your TLS connection? By Maarten Smeets

image

In a previous blog I have explained which what cipher suites are, the role they play in establishing SSL connections and have provided some suggestions on how you can determine which cipher suite is a strong cipher suite. In this blog post I’ll apply this knowledge to look at incoming connections to Oracle Mobile Cloud Service and Integration Cloud Service. Outgoing connections are a different story altogether. These two cloud services do not allow you control of cipher suites to the extend as for example Oracle Java Cloud Service and you are thus forced to use the cipher suites Oracle has chosen for you.

Why should you be interested in TLS? Well, ‘normal’ application authentication uses tokens (like SAML, JWT, OAuth). Once an attacker obtains such a token (and no additional client authentication is in place), it is more or less free game for the attacker. An important mechanism which prevents the attacker from obtaining the token is TLS (Transport Layer Security). The strength of the provided security depends on the choice of cipher suite. The cipher suite is chosen by negotiation between client and server. The client provides options and the server chooses the one which has its preference.

Disclaimer: my knowledge is not at the level that I can personally exploit the liabilities in different cipher suites. I’ve used several posts I found online as references. I have used the OWASP TLS Cheat Sheet extensively which provides many references for further investigation should you wish.

Method

Cipher suites

The supported cipher suites for the Oracle Cloud Services appear to be (on first glance) host specific and not URL specific. The APIs and exposed services use the same cipher suites. Also the specific configuration of the service is irrelevant we are testing the connection, not the message. Using tools described here (for public URL’s https://www.ssllabs.com/ssltest/ is easiest) you can check if the SSL connection is secure. You can also check yourself with a command like: nmap –script ssl-enum-ciphers -p 443 hostname. Also there are various scripts available. Read the complete article here.

Open Banking based on API Platform Cloud Service – support Payment Services Directive (PSD2) EU Regulation

image

Revised Directive on Payment Services or PSD2 is aimed at further developing an EU-wide market for electronic payments. Member states have to transpose the directive into their national laws till January 2018.

Payment service user must have an overview of financial situation at any given moment and have aggregated online information on payment accounts held with other payment service providers, particularly payment account transaction and balance data, all within a secure environment, with strong customer authentication, via application programming interfaces (APIs).

PSD2 contemplates a simplified payments value chain in which the card network can be fully disintermediated. In addition to the dramatic erosion of their payments revenues, banks are also set to see their interest-based revenue streams impacted by a loss of ‘customer ownership’. Account-data aggregators aiming to pull account information from multiple banks into their application, are warning for banks, unless banks themselves also become aggregators of choice.

By offering ‘payment initiation provider’ and ‘account information provider’ services – a bank could significantly improve its ability to sell customer insights, due to the increased availability of customer data and touch points.

Oracle API Platform Cloud Service (APIPCS) simplifies and accelerates the process of delivering open banking and PSD2 compliance by enabling speedy and secure delivery of banking APIs. APIPCS increases level of comfort that businesses are gaining in having their applications and data outside the security of their on‐premises firewalls.

image

APIPCS offers full life cycle API management: planning, design, implementation, publication, operation, consumption, maintenance and retirement of APIs. It includes a developer’s portal to target, assist and govern the communities of developers who embed the APIs, as well as the runtime management and analytics.

APIPCS provides key features of API platform: (i) Building APIs – Creating an API on top of a service that, for example, accesses data formerly locked inside monolithic applications. Rapid API construction with run‐ready policies for controlling usage of APIs; (ii) Securing APIs – Assigning industry‐standard securities to APIs with no coding. Integration with existing enterprise identity management systems; (ii) Deploying APIs – Once the APIs are created, they’re deployed to an API gateway for usage with one‐click. Gateways can run in the Oracle Cloud or on‐premises, close to back‐end services; (iii) Publishing APIs – Documentation can be auto‐generated while the API is being developed; (iv) Consuming APIs – Centralized location for finding and learning about available APIs. Simple approach to register applications so they can utilize APIs; (v) Monitoring APIs – Instant visibility into operational metrics on usage and API business key performance indicators.

In API preparation phase value of APIPCS leads to increased consistency and improves the overall developer experience with formalization of domain semantics or architectural style. Using APIPCS it is possible design and prototype API without writing any code and enable quick iteration on API design change, it is allowed to start of a work on API client before API server is implemented and this way getting very fast feedback from API consumers and stakeholders and provide ready API product much sooner to the market.

The API implementation will be automatically tested against its design, monitoring the contract and implementation changes are made much easier, version control and collaboration comes seamless as well as reporting on any disparities and errors in the description against the results of locally run API, automatic test runs when anything changes.

General differentiators of APIPCS are : it is easy to use and not technically challenging solution; it has focus on ‘API design first’ approach; it has architecture with API management on the cloud (including main portal and developer portal) and only gateways (GWs) being weather on cloud or on-prem. An end customer needs to operate only the gateways (GWs) and APIPCS operates all complex parts of API management in Oracle cloud.

GWs themselves are very mature product with amount of advantages. Management console never goes directly to the GW, it is other way around that only GW goes to cloud – this way providing very elegant security solution. GWs will automatically pull down all new policies. In case of APIPCS, most policies will work with existing versions of the GW, so GW upgrades are minimal and if they are required it will anyway happen through the cloud service. APIPCS pulls down the deployments of GWs extremely fast, as they are done by the cloud service, without need to export a zip or manually deploy GWs. There is no need end customer to perform data backups, no need for upgrades to get new policies, no need to configure clusters. All these brings down operational cost of operating API platform. APIPCS gives control which users have the right to deploy which GWs and what exactly is deployed on which GW, with full audit history.

Want to learn more? Contact Milomir Vojvodic