OSB-12c : Write into File

-
OSB-12C supports messages in text format. We can use 'Text' message type in both proxy and business services.

Sample use-case:

1. Send message in text format to proxy service.
2. Text request will be routed to File protocol based business service and writes contents of Text message into file with .txt extension.

Create new folder inside MessageType_Service
File -> New -> Folder -> Text_MessageTypeServices along with sub folders.


Create new file protocol based business service.


Give service name and specify protocol for business service.
Service Name: WriteFile
Transport: File
Messaging Req: Text
     Resp: None





Specify End point URI, the location in which you want to write contents of file.
End point URI: file:///Oracle12cPOC/WriteFile





Create new pipeline in design view


Provide Service name and specify transport protocol and message type for proxy service.
Service Name: Test_MessageTypeProxyService
Transport: http
Messaging Req: Text
      Resp: XML








Add a route node and route incoming request to WriteFile.bix business service




In Request Action of Route node add a replace action, to replace body of incoming request.


In Response Action of Route node add a replace action and specify expression as below.
<FinalResponse>
<Code>000</Code>
<Desc>Text Message Type tested successfully.</Desc>
</FinalResponse>



Deploy service into standalone local server. Once deployment is success, we can locate service in sbconsole.



Run ‘Text_MessageTypePipeline’ and provide some valid text message in request part.



We can see that request is routed to WriteFile business service by trace. Once execution of request is success we will static success response as below.



Now you can migrate to specified File writing location and we can see that file is getting created with .txt extension.



Location: Bengaluru, Karnataka, India

Comments

Post a Comment

Popular posts from this blog

OSB-12C : XA Transactional Support feature

-
Image
OSB 12c supports both XA as well as Non-XA transactions. An XA transaction is a "global transaction" that may span multiple resources. It involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like WebSphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP etc) acting as transaction resources.  Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are committe...
Read more

Static code analysis of Terraform .tf files using ‘Checkov’ — Secure your infrastructure

-
Image
  Hands on shelf! We can all agree that Terraform is great tool for infrastructure creation and provisioning. When we write terraform .tf files for infra creation we might miss something and we add something which can lead to security issues. Security should be prime factor for any devops related use-case. When I was searching internet for is there any tool which will scan terraform files and give a picture what may go wrong (from security perspective), I came across this very useful tool named ‘Checkov’ Link :  https://www.checkov.io/1.Welcome/Quick%20Start.html Checkov is a   static code analysis tool for scanning infrastructure as code (IaC) files for misconfigurations that may lead to security or compliance problems. Checkov includes more than 750 predefined policies to check for common misconfiguration issues. In this post, I am going to discuss how to do static code analysis of terraform tf files using checkov. step 1 : Install checkov in your machine. $ pip install...
Read more

OSB12c : Schema Validation - Dynamic Validation

-
Image
We can use validate node in OSB to validate schema. There was an option to validate the payload in OSB 11g but it was static, however from 12c there is a new feature included in the OSB validation activity that is validating the data dynamically. This will allow the user to validate the input data or other data dynamically based on certain condition. Thus the process can be stopped at the beginning itself the data validation goes wrong. You have the option to save the validation result or raise an error. Use case: 1. Create a WSDL based service 2. Add validate (dynamic) to validate incoming request structure. 3. If any violation in request structure compared with schema, Error will be raised with proper error code and description. Create new folder and name it as ‘DynamicValidateSchema_UseCase’. Create sub folders structure as shown in below image. For this use case we have created two XSDs and placed it inside Resources -> XSD folder EmployeeDetailsReq...
Read more