12c SOA Weblogic - how to apply patch in weblogic server

Steps for applying patch:

Step1: Stop all servers and clean out the domain_home/servers/<server>/ 'tmp', 'cache' and 'stage' folders.

Step2: Set oracle home and test the opatch version. Set the ORACLE_HOME environment variable to the directory where you have installed Oracle SOA Suite.
cd /app/Oracle/Middleware/Oracle_Home/OPatch  export ORACLE_HOME=/app/Oracle/Middleware/Oracle_Home

opatch version 

opatch lsinventory

Step3: Copy patch file and unzip the .zip folder in unix directory like /soashare/patch.
Copy downloaded patch file in both node of server /tmp/soadev directory using WinScp 

• Change the permission of downloaded patch

                chmod 777 p22337707_122100_Generic.zip 

•       Move downloaded patch from /tmp/soadev directory to /soashare/patch directory

                mv p22337707_122100_Generic.zip /soashare/patch
                cd /soashare/patch

          chmod 777 p22337707_122100_Generic.zip

•  Unzip the patch zip file into the PATCH_TOP folder.

Note: Rename existing “PATCH_TOP” folder in /soashare/patch to “PATCH_TOP_<<Name of last patch applied>>”

unzip -d PATCH_TOP p22337707_122100_Generic.zip

Step4: Apply patch  

    Set your current directory to the directory where the patch is located.

    cd PATCH_TOP/22337707       

    $ORACLE_HOME/OPatch/opatch apply

Step5: Check the applied patch

   $ORACLE_HOME/OPatch/opatch lsinventory

Step6: Follow above steps 2-4 in node 2.

Step7: Start all Servers.

++END++

Patch applied in production:

1. Patch 22337707: Naming conflict with EDN event subscribers from single Mediator component

SYMPTOMS: When you are deploying a composite defined with one Mediator and 5 events subscriptions you are expecting durable subscriptions (JMS) to 5 events. Instead only 3 subscriptions are created so 2 events aren't "read".

CAUSE: Bug 22337707 - Deploying composite doesn't create enough durable subscribers (JMS) for EDN.

The problem seems to be related to a naming convention problem. The event Subscription Name in JMS is comprised of the first 10 characters of the Event Name + the Instance ID.

For example:

Abcdefghij_SCA_220103

So in the case of the two events below, only one subscription can be created due to a naming conflict:

AbcdefghijklEventOne

AbcdefghijklEventTwo

Reference doc:

Composite deployment fails to create enough durable subscribers (JMS) for EDN (Doc ID 2091244.1)

2. Patch 22385445: Flow Trace working too long or not loading at all

SYMPTOMS: When selecting the Flow ID in the EM console, the audit trail page hangs and it either takes a while to appear or it never appears at all.
CAUSE: Issue due to Bug: 22385445 12.2.1.0.0 Flow Trace working too long or not loading at all
Reference doc:
SOA 12c: It takes a very long time to display the flow trace in EM or it fails to display at all (Doc ID 2208520.1)

3. Patch 23138916: MERGE REQUEST ON TOP OF 12.2.1.0.0 FOR BUGS 21549249 21572567
Bugs Resolved by This Patch
21549249      cannot insert NULL into SOAINFRA.AUDIT_DETAILS.CI_PARTITION_DATE

21572567      composite instance id not restored during non-SOA ws callback

4. Patch 25388847: WLS PATCH SET UPDATE 12.2.1.0.170418 (Supersede of patch 24904865)
Bugs Resolved by This Patch
21495475      Fix for Bug 21495475
22049932      Fix for Bug 22049932
22175246      Fix for Bug 22175246
22200449      Fix for Bug 22200449
22200491      Fix for Bug 22200491
22200523      Fix for Bug 22200523
22200594      Fix for Bug 22200594
22241704      TRACKING BUG FOR BACKPORT BUG 21621232
22247869      Fix for Bug 22247869
22248079      Fix for Bug 22248079
Reference Document:

SOA 12.2.1 Enterprise Manager Latency (Doc ID 2240093.1)

5. Patch 23762529: MT: STRESS:WLS: MBEANS TAKING MORE TIME
Bugs Resolved by This Patch

23762529      MT: STRESS:WLS: MBEANS TAKING MORE TIME

6. Patch 24327938: TOPLINK SECURITY PATCH UPDATE CPUJUL2016
Bugs Resolved by This Patch

23630882        Fix for Bug 23630882

7. Patch 22090514: "new code mTestMeadataMgr=null" data in server out file
Reference Document:

new code mTestMeadataMgr=null", in the SOA server .out log (Doc ID 2104408.1)

8. SOA 12.1.3: Undo tablespace becomes exhausted during purge operations (Doc ID 2224031.1)
Bug 24558237 - Purge causing'ORA-01652 or 'Undo tablespace full' on DOCUMENT_DLV_MSG_REF

determined this was a problem on the scripts

12c Jdeveloper - How to create integrated Application server to deploy composites directly to server

Step 1: Go to windows tab >> Application servers.

Step 2: Right click on the Application Servers and click on New Application server.

Step 3: Choose Integrated Server.

Step 4: Provide a name 

Step 5: Provide User and Password.

Step 6: Provide the host,domain names etc.

Step 7: Test connection .

How to use Configuration file to customize OSB deployments

When we are deploying Oracle Service Bus projects to a new environment, we need to change some values such as Web Services endpoints, DB JNDI Names, AQ JNDI Names, LDAP JNDI Names etc. In order to achieve automated changes to your resources, Oracle suggests using Configuration Files which apply customization rules to them.

In order to create a Configuration,
File first we should deploy the project with the initial implantation, which typically contains some proxy, pipelines and business services. Then we log in to Service Bus console and navigate to Admin tab:

Click "Create Configuration File"

Select the projects where to use the customization

Press create button and it will create the following file:

 OSBCustomizationFile.xml

We may edit those blocks with the desired values and execute the new configuration file from the service bus console by selecting the Execute Configuration File option mentioned above.

Take the session and click "Execute Configuration File" and upload the customized file and finish it.

Note:

If you need to change any configurations used in the pipeline, you need to manually modify the same from the pipeline. you can't change the pipeline configurations using the configuration files.

OSB - How to pass Authorization header from Pipeline

Step 1: Drag and drop assign activity.

Double click assign activity and give expression.

Note: This is input variable ($body/ttur:RequestReportName/ttur:accessToken)

Step 2: Create one variable and mention in variable part.

Step 3: Drag and drop Transport Header in inside service callout.

Double click Transport Header and select direction.

Step 4: Create one Authorization header name and give expression.

Step 5: Give expression.

Note: (Expression: fn:concat('Bearer ',$varAccessToken))

varAccessToken is variable.

12c Jdeveloper IDE installation steps - version 12.2.1.0.0

Step 1: Download the software from the following Oracle link:

https://www.oracle.com/middleware/technologies/soasuite/downloads.html

In this link, you will get 12.2.1.4.0 quick start. Click download link for SOA Suite product and Download 1st 2 files.

Step 2: Keep the downloaded 2 files in a folder:

Note: JDK 8 should be installed. This case installed version is jdk1.8.0_51.

Step 3: Open the command prompt and run the following command:

cd C:\Program Files\Java\jdk1.8.0_51\bin 

C:\Program Files\Java\jdk1.8.0_51\bin>java.exe -jar D:\Softwares\SOA12c\fmw_12.2.1.0.0_soa_quickstart.jar

Step 4: It will start the Oracle Universal Installer wizard. select the oracle home path and go to next.

Step 6: Click Next to finish.

Oracle SOA 12c Features

Oracle has released SOA Suite 12c and lots of new features are introduced in this release.

List of some of the new features:

Single Installer: Oracle Suite 12c comes as single installer for developers that means you only need to install only one setup (SOA Suite 12c), DB/Weblogic/SOA will get installed. Oracle SOA 12c use Java Derby database, which is file based and that makes it really fast.

Single IDE: In Oracle SOA 12c Jdeveloper is used as IDE for all designs. For OSB development we don't need to use different IDE (Eclipse) anymore, we can develop OSB application in Jdeveloper itself.

Debugger and refactoring: These are new features in Oracle SOA 12c, debugger and refactoring are introduced to debug and refactor SOA and OSB applications. With the help of debugger we can debug our code before deploying it; this saves lot of development efforts. We can also change message text while debugging it.

Dependency Explorer: This allows to "visualize" the dependencies between various SOA composites as well as Service Bus projects which typically consist of fair number of artifacts that hang together in ways that are sometimes not so easy to track down. It will leverage all its built in knowledge about potential dependencies and it will visualize these dependencies

Graphical MDS: In Oracle SOA 12c graphical tool is provided to publish, search and consume files from MDS and OER.

SOA Templates: With the introduction of templates sharing of code between teams become earlier and development efforts reduced. There are three types of templates introduced.

Project Template
Component Template
Custom Activity Template

BPEL Sub-process: Sub-process is introduced in this launch which helps to reduce redundancy. Suppose we need to update database table 3 times in one flow so instead of add 3 different invoke to same BPEL, create sub-process which update the database table and use that sub-process 3 times in that BPEL. There are two types of sub-processes.

Standalone sub-process
Inline sub-process

Re-sequencing in OSB: In 11g this feature was available in Mediator, in Oracle SOA 12c this features added to service bus also, with the help of this feature we able to process the request message in proper sequence.

Adapter: Coherence, LDAP and cloud, REST, UMS, MFT qnd MSMQand Oracle adapter for SAP R/3 are introduced in this release.

Xquery Mapper: In this release Xquery mapper is introduced which provide XQuery support.

Enterprise Service Scheduler: ESS is out of box scheduler. By using this we can schedule the services.

Translate Activity:  Translate activity is also introduced which is used for Native to XML and XML to Native transformation.

MDS support for OSB: In 11g version MDS support was not there for OSB but in 12c MDS support is provided for OSB.

File Based MDS:
In addition to the existing run-time Meta Data Services Repository, Oracle SOA Suite 12c adds a file-based SOA Design-Time MDS Repository for use during design time. The repository is automatically created when you create a SOA composite application and will typically point to the version control system location.

Encrypt/Decrypt Personally-Identifiable Information (PII): It assists in Protecting sensitive data from appearing in the Admin consoles in clear text.

For example a Social Security Number or Credit card Number. Specific Fields in a message can be encrypted when entering the SOA composite application in the service binding component, and decrypted while exiting the application in the reference binding component. It is available for services and adapters in both SOA (SCA Composite) and Service Bus. The PII policy is attached to the SCA Composite. The credentials/encryption to use is configured on WLS and is stored using the Credential Store framework (CSF).

Splitting Proxy from Pipeline:
Because a SB project is more like a SCA Composite (same overview) the Proxy is split from the Pipeline. This means that the Proxy and the Pipeline are two individual things. With this concept multiple Proxies can be wired to one Pipeline.

Enterprise Manager instead of SBConsole:
The Service Bus console has found a new home with the switch to JDeveloper. Most functionality is moved to the Enterprise manager.

Fault Policy Editor:

1. Design and Edit Fault Policies.
2. Besides the already existed functionality a lot of new features are added.

• Graphical editor for creating Fault policies, Alerts, Actions & Property Sets.
• New Default actions for invoking a WS and enqueue data (JMS).
• Alerts can be defined to send fault to JMS, Email or Log file.
• Alerts can be assigned to actions if type of Alert is desired to be triggered.
• Fault Policies can be coupled, using the Composite Binding dialog, to different levels:

        composite
        component
        reference binding
        service binding

OSB - Enable/Disable proxy service

If you are using an OSB Proxy Service for polling and want to enable/disable the service, you can easily do carrying out the below steps.

11g Steps:

1. Login to sbconsole. http://hostname:port/sbconsole
2. Select the Proxy service
3. Click on 'Operational Settings' tab
4. Create session, uncheck the checkbox to disable state.
5. Activate your changes.

12c Steps:

1. Login to the OSB domain EM console.http://hostname:port/em
2. On the left Navigation tab, under SOA click on the service-bus
3. On the service-bus page click on 'Operations' tab.
4. Search for the Proxy service
5. Uncheck the box under State column
6. Apply
7. Test

Difference between XA and Non-XA Datasource

XA Datasource:

• In simple term, XA datasource is a "global transaction" that may span multiple resources. 
• An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. 
• It supports two way commit operation.

For an instance:
We have a SOA service updating more than one database table using update queries. If all the queries are dependent on each other and any of the query gets failed while updating table then the whole transaction will be rolled back. So this is a “global transaction”. If we “commit”, it will do commit across all the resources and “rollback” will revert all of the resource’s updates done in the transaction.

Conclusion: It has transaction coordinating manager that allows to handle multiple requests spanning over multiple resources.

Non-XA Datasource:

• In simple term, Non XA datasource supports “single transaction”or local transactions.
• Non XA transaction always commit/rollback single resource/operation. 
• Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself.

For an instance:
If we have a SOA service updating multiple DB queries independently and there is no relationship in the queries, If any of the queries failed, there will be no impact on other queries and each can be locally committed or rollbacked.

Conclusion: It has no transaction coordinating manager that’s why it can handle one request at a time.

Comparison:

1. XA datasource support global transaction, so it requires less database transaction compare to Non XA datasource.
2. If you got multiple requests at a time, there might be a chance of getting Non XA connection pool full and causing failure.

Interaction Patterns in a BPEL Process

Interaction Patterns in a BPEL Process

This describes common interaction patterns between a BPEL process service component and an external service:

Interaction patterns:

1. One-Way Messages
2. Synchronous Interactions
3. Asynchronous Interactions
4. Asynchronous Interactions with a Timeout
5. Asynchronous Interactions with a Notification Timer
6. One Request, Multiple Responses
7. One Request, One of Two Possible Responses
8. One Request, a Mandatory Response, and an Optional Response
9. Partial Processing
10. Multiple Application Interactions

One-Way Messages: 
In a one-way message, or fire and forget, the client sends a message to the service and the service is not required to reply.

Synchronous Interactions:
In a synchronous interaction, a client sends a request to a service and receives an immediate reply. For example, a user requests a subscription to an online newspaper and immediately receives email confirmation that their request has been accepted.

Asynchronous Interactions:
In an asynchronous interaction, a client sends a request to a service and waits until the service replies.

Asynchronous Interactions with a Timeout:
In an asynchronous interaction with a timeout (which you perform in BPEL with a pick activity), a client sends a request to a service and waits until it receives a reply, or until a certain time limit is reached, whichever comes first. For example, a client requests a loan offer. If the client does not receive a loan offer reply within a specified amount of time, the request is canceled.

Asynchronous Interactions with a Notification Timer:
In an asynchronous interaction with a notification time, a client sends a request to a service and waits for a reply, although a notification is sent after a timer expires. The client continues to wait for the reply from the service even after the timer has expired.

One Request, Multiple Responses:
In this interaction type, the client sends a single request to a service and receives multiple responses in return. For example, the request can be to order a product online, and the first response can be the estimated delivery time, the second response a payment confirmation, and the third response a notification that the product has shipped.

One Request, One of Two Possible Responses:
In an interaction using one request and one of two possible responses, the client sends a single request to a service and receives one of two possible responses. For example, the request can be to order a product online, and the first response can be either an in-stock message or an out-of-stock message.

One Request, a Mandatory Response, and an Optional Response:
In this type of interaction, the client sends a single request to a service and receives one or two responses. Here, the request is to order a product online. If the product is delayed, the service sends a message letting the customer know. In any case, the service always sends a notification when the item ships.

Partial Processing:
In partial processing, the client sends a request to a service and receives an immediate response, but processing continues on the service side. For example, the client sends a request to purchase a vacation package, and the service sends an immediate reply confirming the purchase, then continues on to book the hotel, the flight, the rental car, and so on. This pattern can also include multiple shot callbacks, followed by longer-term processing.

Multiple Application Interactions:
In some cases, there are more than two applications involved in a transaction, for example, a buyer, seller, and shipper. In this case, the buyer sends a request to the seller, the seller sends a request to the shipper, and the shipper sends a notification to the buyer. This A-to-B-to-C-to-A transaction pattern can handle many transactions at the same time. Therefore, a mechanism is required for keeping track of which message goes where.

BPEL Transaction and Delivery Policies

 BPEL Transaction and Delivery Policies:

Transaction boundaries between different BPEL services are controlled by 2 properties
 1) Delivery Property
 2) Transaction property

Case 1: If BPEL Process is Async or one-way process then, Delivery policy attribute can have three values.
 1) async.persist
 2) async.cache
 3) sync

async.persist: Delivery messages are persisted in the database in table dlv_message of the dehydration store . With this setting, reliability is obtained with some performance impact on the database. When the client initiates a process instance, an invocation request is placed in an internal queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests. When a message is dequeued, Oracle BPEL Server allocates a thread to process the message.

   <component name="AsyncBPELProcess" version="2.0">
    <implementation.bpel src="BPEL/AsyncBPELProcess1.bpel"/>
    <property name="bpel.config.oneWayDeliveryPolicy" type="xs:string" many="false">async.persist</property>
  </component>

async.cache : Incoming delivery messages are stored in the in-memory cache. If performance is preferred over reliability, this setting should be considered. Message are not dehydrated into dlv_message table. Rest all is same as async.persist.

  <component name="AsyncBPELProcess" version="2.0">
    <implementation.bpel src="BPEL/AsyncBPELProcess1.bpel"/>
    <property name="bpel.config.oneWayDeliveryPolicy" type="xs:string" many="false">async.cache</property>
  </component>


sync : The service engine uses the same thread to initiate the message.Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.


  <component name="AsyncBPELProcess" version="2.0">
    <implementation.bpel src="BPEL/AsyncBPELProcess1.bpel"/>
    <property name="bpel.config.oneWayDeliveryPolicy" type="xs:string" many="false">sync</property>
  </component>

Notes:

1. Transaction property is not supported in oneway/ Async BPEL process.
2. Specify bpel.config.oneWayDeliveryPolicy in the BPEL process service component section of the composite.xml file. If this value is not set in composite.xml, the value for oneWayDeliveryPolicy in the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control is used.

Case 2: If BPEL Process is Sync process then, transaction context between client and bpel-process is controlled by "Transaction" Attribute.
Values of these attributes are 
 1) Required 
 2) Requires New

Required :  
In request/response (initiating) environments, this setting joins a caller's transaction (if there is one) or creates a new transaction (if there is no transaction).In one-way, initiating environments, in which the Delivery list value (oneWayDeliveryPolicy property) is set to sync, the invoke message is processed using the same thread in the same transaction.

  <component name="SyncBPELProcess" version="2.0">
    <implementation.bpel src="BPEL/BPELProcess1.bpel"/>
    <property name="bpel.config.transaction" type="xs:string" many="false">required</property>
  </component>

RequiresNew : 
A new transaction is created for the execution, and the existing transaction (if there is one) is suspended. This behavior is true for both request/response (initiating) environments and one-way, initiating environments in which the Delivery list value (oneWayDeliveryPolicy property) is set to sync.

 <component name="SyncBPELProcess" version="2.0">
    <implementation.bpel src="BPEL/BPELProcess1.bpel"/>
    <property name="bpel.config.transaction" type="xs:string" many="false">requiresNew</property>
  </component>

Looking at the wsdl how can you identify whether the process is one way/sync/async?

Looking at the wsdl how can you identify whether the process is one way/sync/async?

If we check the portType in the wsdl, we can easily identify whether it is one way/sync/async:

oneway: Only input exists in the portType and  in partnerLinkType only one role is there i.e Requester Role no provider.

<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input  message="client:BPELProcess1RequestMessage" />
</wsdl:operation>
</wsdl:portType>

async: Only input and Callback part exists in the portType and in PartnerLinkType two roles will be there  ProviderRole n Requester Role.
<wsdl:portType name="BPELProcess1Callback">
<wsdl:operation name="processResponse">
<wsdl:input message="client:BPELProcess1ResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
<plnk:partnerLinkType name="BPELProcess1">
<plnk:role name="BPELProcess1Provider" portType="client:BPELProcess1"/>
<plnk:role name="BPELProcess1Requester" portType="client:BPELProcess1Callback"/>
</plnk:partnerLinkType>

sync: Both input and output segments exist in the portType and , in partnerLinkType only one role is there i.e Provider Role.
<wsdl:portType name="BPELProcess1">
<wsdl:operation name="process">
<wsdl:input  message="client:BPELProcess1RequestMessage" />
<wsdl:output message="client:BPELProcess1ResponseMessage"/>
</wsdl:operation>
</wsdl:portType>

<plnk:partnerLinkType name="BPELProcess1">
<plnk:role name="BPELProcess1Provider" portType="client:BPELProcess1"/>
</plnk:partnerLinkType>

Abstract WSDL vs Concrete WSDL

Abstract WSDL vs Concrete WSDL

A WSDL structure:

A typical WSDL (Web Services Description Language) consists of the following sections; types, messages, portType, binding & service elements. A quick look at what each of these sections define will ease the task of clarification of the differences;

Types - Defines the data type definitions for messages that will be exchanged by the web service. Generally defined the schema (XSD).

Message - Defines the set of actual messages that will be exchanged. A message can consist of one or more parts which is a logical separation which together constitutes the message.

PortType - Defines the abstract operations provided/available and abstract messages involved. Operation refers to the messages involved in the transaction.

Bindings - Defines the message format and protocol information for operations defined by the portType.

Service - Defines the endpoint where the webservice will be exposed.

Abstract WSDL(Types, Message and PortType):
It describes what the web service does, but not how it does it or how to contact it.
An abstract WSDL document defines:
- the operations provided by the web service.
- the input, output and fault messages used by each operation to communicate with the web service, and their format.
- Used on server side.
- Abstract WSDL is reusable because there is no binding details in it whereas Concrete WSDL used for specific service for which it is defined.

Concrete WSDL(Types, Message, PortType,Bindings and Services):
It adds the information about how the web service communicates and where you can reach it.
A concrete WSDL document contains the abstract WSDL definitions, and also defines:
- the communication protocols and data encodings used by the web service.
- the port address that must be used to contact the web service.
- Used on client side
- concrete WSDL contains messages, operations and binding/transport specific information i.e. SOAP over Http/HTTPS/JMS having wsdl style i.e. RPC/DOC literal

Abstract vs Concrete

When to use Abstract and Concrete WSDL:

1. Suppose we have a service which calls another service within the application and if we are using concrete wsdl then we can face the caller service loading issue or caller service is in invalid state.This is because of the usage of concrete WSDL reference where the referenced service is not available yet when the caller service composite starts up. To avoid such scenario, we have to use abstract wsdl and provide the endpoint in the location reference section of the composite.xml.
2. Suppose if we have a service and that need to be shared with the external client who will consume this service, in this scenario, we have to use concrete wsdl to provide the address of service/endpoint to be communicated.
3. MDS is generally used for within SOA application services, so we need to import abstract wsdl in MDS and use respective services to enhance the re-usability of the services.

XSLT Transformation file Design View not opening in Jdeveloper

XSLT Transformation file Design View not opening in Jdeveloper

Solution:

step 1:

Add the following Oracle-xsl-mapper before template match with the correct WSDL path, element name and namespaces:

<?oracle-xsl-mapper

   <mapSources>

    <source type="WSDL">

      <schema location="../sourceWsdlName.wsdl"/>

      <rootElement name="sourceRootElement" namespace="sourceWsdlNamespace"/>

    </source>

  </mapSources>

  <mapTargets>

    <target type="WSDL">

      <schema location="targetWsdlLocation"/>

      <rootElement name="targetRootElement" namespace="targetNamespace/"/>

    </target>

  </mapTargets>

 ?>

step 2:
Restart the Jdeveloper and open.

12c SOA Weblogic - Node Manager is inactive or unreachable

Node Manager is inactive or unreachable

Problem description:  

Sometimes Node manager Status is showing Inactive and shows below error:    

weblogic.nodemanager.NMConnectException

Solution:

Step1: 

Shutdown all the servers and Admin from admin console.

Step2: 

Go to unix/AIX box and to DOMAIN_HOME/bin folder and run nodemanager.sh in both nodes(if its clustered).

nohup startNodeManager.sh &

Step3:
Start the admin server 

go to DOMAIN_HOME/bin folder  and run the following command.

nohup ./startWebLogic.sh > /dev/null 2>&1&

Step4: 

Go to Admin console and check  Domain>>Environment>>Machines>>click on one machine >>Go to Monitoring Tab and check status. It should be reachable now.

SOA 12c Jedeveloper - Flow designs in OSB servicebus.sboverview is not showing or loading issue.

Flow designs in OSB servicebus.sboverview is not showing or loading  issue:

Solution:

In the JPR-file, there is a part called technologyScope:

   <hash n="oracle.ide.model.TechnologyScopeConfiguration">

      <list n="technologyScope">

         <string v="SOA"/>

         <string v="ServiceBusTechnology"/>

         <string v="WSDL"/>

         <string v="WSPolicy"/>

         <string v="XML"/>

         <string v="XML_SCHEMA"/>

      </list>

   </hash>

We just need to delete the part “<string v="SOA"/>” from the technologyScope and restart the jdeveloper tool and its started showing the flows/diagrams in design view.