Bash Shell script - all in one place

 

Bash scripting - part1 - introduction variable loops decision making statements comments

Bash scripting - part2 - positional params STDIN sourcing a config return code exit functions

Bash scripting part3 - variable scope let case eval wildcards logger reading a file line by line expr loop control statements debugging

Bash scripting - part4- SED awk

OIC - Fault return - send custom fault to modeled soap trigger

Here, I will describe how we can send custom faults to a modeled soap trigger.

Use case:

We will create a soap trigger connection based on a request response and modeled fault wsdl and from the integration, will call an external rest service and the twist is, we will provide invalid rest url and keep all this activities in a scope and from scope APIInvocationError we will customize the fault to the modeled soap to consumer.

Implementation steps:.

Step1: First we should have a request-response with modeled fault wsdl. Then create a soap trigger connection using the wsdl.

Fault schema contains errorCode,error and error details fields.

Step2: create a rest invoke connection using external or internal OIC rest service URL. 

Here, I used the following url:.

https://jsonplaceholder.typicode.com/users/1.

Step3: create an app driven integration and configure the soap trigger using the created soap trigger connection.

Step4: create a scope and drag and drop created rest invoke connection and configure it with all details

Endpoint name,

Uri: /1users/{User-id} // purposefully provided wrong uri.

Verb: get

In response section, provide the rest Json response payload

Next map the id and map the response to the soap trigger.

Now the integration flow looks as

Step5: click on the fault handler and choose APIInvocation error. Drag and drop Fault return action and map the $CurrentFaultObject details to soap modeled fault.

Note: you can also define default fault handler.

Step6: save, add tracking id and activate and test with input. You will see your modeled error as below screenshot:

OIC - Fault Return action - Custom HTTP Error response in rest flows

Why Fault return:

The REST adapter allows to expose the HTTP endpoint that HTTP clients can request and returns an HTTP response. On successful call, it gets a HTTP status code with the response. On error, it returns an error response with an HTTP status  belonging to the HTTP error family of codes depending on the fault situation.

Using this Fault return action, we can send custom error response to the consumer. For example,

We can send 400 Bad request, if some manadatory params are missing.

Use case:

We will create an app driven service and use rest service trigger with input query field "id" and response "name". We will create a logic, if id is not empty then harcode a name to the response otherwise we will take a fault return action and send a custom error message to the consumer.

Steps of implementation:

Step1: Create an appdriven integration and drag and drop rest trigger connection and configure :

Endpoint name

URI: /custom

Verb: get

Add and review params for this endpoint

Configure this endpoint to receive the response

Next

Add Query parameter 

Name: id and data type : string

In response section, choose JSON and inline and write as below

{

"Name":"samplename"

}

Next

Done.

Now the integration flow look like:

Step2: add a switch action and add the following condition

Id !=""

And hardcode a name to the response.

Step3: in the otherwise block,  add fault return activity and map the error code, type error details as customized as per your requirement.

Here, I have customize erros as below:

Error code: '400'

Type: '400, Bad Request'

Title: 'id field value is empty or missing'

Now the Integration flow looks as below

Step4: add tracking as id, save, activate and run test with empty id. You will see your customized error:

OIC - 1Z0-1042-21 - topics to be covered for Certification

Collected from Oracle site:

Exam topics:

Getting Started with Oracle Cloud Application Integration

• Describe the key features & components of Application Integration

• Explain Application Integration concepts

• Describe Application Integration Architecture
• Explain WSDL, XML/SOAP, WS, and REST/JSON functionality

Working with Integrations in Oracle Integration Cloud

• Understand OIC components, features, and capabilities
• Create and configure connections (Adapter, Trigger, Invoke)
• Create Integrations (App Driven and Scheduled Orchestrations)
• Map data using Lookups and the Data Mapper
• Explain On-Prem connectivity agents (architecture, capabilities and scheduling)
• Explore Oracle Integration Cloud best practices
• Understand file handling options, features and capabilities
• Leverage orchestration action, scopes and fault handling
• (New)Explore File Server use cases
• (New)Develop B2B Flows in Oracle Integration (Inbound & Outbound EDI documents; Using the B2B Action)

Working with Service-Oriented Architecture Cloud Service (SOACS)

• Describe Concepts of Service orchestration, Adapters, Routing, and Security Policy
• Perform administration and application lifecycle tasks using SOACS user interfaces
• Build and deploy composite applications to Oracle SOA Cloud
• Understand Oracle Managed File Transfer on OCI

Working with API Platform Cloud Service

• Manage Users (user management concepts and personas, create users and groups, assign roles to users and groups)
• Manage Gateways (install and configure gateway nodes, issue gateway grants, configure OAuth 2.0 Providers)
• Manage APIs (implement an API, deploy to a gateway, add documentation, publish to the Developer Portal, issue API grants, apply policies)
• Manage Services and Service Accounts
• Use the Developer Portal (discover and register to APIs)

Working with Processes in Oracle Integration Cloud

• Develop Business Processes; Integrate with Applications and Services
• Create Human Tasks and Web Forms
• Manage Application Data
• Create Decisions

(New)Working with Integration Insight in Oracle Integration Cloud

• (New)Work with Insight models (creating, activating & deactivating, exporting & importing, deleting & purging)
• (New)Map milestones and analyze business 

OIC - ways of throwing or handling faults

There are following 4 ways we can throw or handle fault in an integration:

• No fault handling
• ReThrow fault
• Throw new fault
• Fault return

No Handling:

• This is only applicable when you don’t have any requirement to handle any fault in a special way. You just let it happen and in case of a synchronous integration let it return he fault details to the consumer.
• But the concern is what fault details we are receiving from OIC that is not the actual fault as thrown by the back-end service. For example, in case the REST back-end service throws a HTTP 404 Not Found, a REST Integration will throw a HTTP 500 Internal Server Error with the actual fault code (404) “hidden” in the errorDetails.title.
• There is no strict standard for it, different back-end systems may have significant differences in the way they throw faults, using different elements, providing a different level of detail. For this reason, in case of a SOAP fault a SOAP Integration will have the original fault details wrapped in CDATA,

Example of rest fault:  we can see OIC is throwing error as 500 internal server error but the original fault 404 is hidden in the errorDetails.title:

{

  "type" : "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1",

  "title" : "Internal Server Error",

  "detail" : "Internal server error. Please contact oracle support for details.",

  "errorCode" : "500",

  "errorDetails" : [ {

    "type" : "UnMappedFault:execute",

    "instance" : "NA",

    "title" : "Fault Details : \n<nstrgdfl:APIInvocationError xmlns:nstrgdfl=\"http://xmlns.oracle.com/cloud/generic/rest/fault/REST/GetEmpDetails\"><nstrgdfl:type/><nstrgdfl:title/><nstrgdfl:detail/><nstrgdfl:errorCode/><nstrgdfl:errorDetails><nstrgdfl:type>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5</nstrgdfl:type><nstrgdfl:title>Not Found</nstrgdfl:title><nstrgdfl:errorCode>404</nstrgdfl:errorCode><nstrgdfl:errorPath>&lt;![CDATA[GET https://jsonplaceholder.typicode.com/1users/1 returned a response status of 404 Not Found]]&gt;</nstrgdfl:errorPath><nstrgdfl:instance>&lt;![CDATA[{}.The HTTP 404, 404 Not Found, and 404 error message is a Hypertext Transfer Protocol (HTTP) standard response code, in computer network communications, to indicate that the client was able to communicate with a given server, but the server could not find the resource that was requested. Carefully re-examine the target endpoint that is being called. ]]&gt;</nstrgdfl:instance></nstrgdfl:errorDetails></nstrgdfl:APIInvocationError>\n:Application Error",

    "errorPath" : "NA",

    "errorCode" : "NA"

  } ]

}

ReThrow Fault:

In this case the fault is thrown to the higher scope without modification. If there is no higher scope, then in case of a synchronous integration the consumer will get the fault as-is and with that the result is the same as when you did nothing.

You use Rethrow Fault when you need to do some steps before raising the fault, like populating a log message or sending an email, but you have no need for a specific way of handling the fault otherwise.

Throw New Fault:

Using Throw New Fault action, we can throw new or custom fault other than the one you caught.

This will give us the opportunity to configure the values of the errore details sub elements. We can throw fault code , reason and details to the higher scope where it will be handled. Customizing the faults, we can represent a clearer view of errors to the consumer or support folks . 

In case of REST service, you can introspect the HTTP error details.title to lookup the original fault and map them accordingly.

Fault Return:

Fault returns are the same like for Throw New Fault. It provides the more control over the fault returned to the consumer.We can use fault return for the following cases:

• If we want to SOAP fault to be more structured and want to send custom fault details to modeled soap trigger.

Click this to know how. oic-fault-return-action-with rest

• If we want the rest fault to return the original HTTP status code which is returned by the back end service. Or custom fault.

Click this to know how oic-fault-return-send-custom-fault with modeled soap

 

python - all links together

 

Install required software and validation

pip install

Modules, Comments & Pip

Variables and Data Types

Strings

Lists and Tuples

Dictionary and Sets

Conditional Expressions or Decision making statements

Loops

Functions and Recursions

File I/O

Object-Oriented Programming

Inheritance & more on OOPs

Exception handling

Virtual env, pip freeze, Lambda function, join method, format method and map, filter, reduce

django - all blog links together

 

🔗Introduction & Install django and PyCharm CE

🔗create your first project and runservers and urls and views

🔗how to use templates

🔗homepage - fetch form textarea value from template to views

🔗webpage to have personal navigations

🔗webpage to input text and remove punctuation from it.

🔗adding Bootstrap to django website

🔗POST request and CSRF tokens

🔗Creating E-commerce website with apps setups