OSB12c : Fixed Length Message Type

-
We can easily transform flat file of fixed length into valid xml using native format builder in OSB-12c.

Sample use-case:

1. Send flat file with fixed length to proxy service.

2. Include nXSD schema in proxy service in order to convert flat file into XML.

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


Create new pipeline in design view 




Specify Messaging type as below
Request: Text
Response: XML



Crate a proxy service with ‘http’ transport protocol
Design view (right click) -> Insert Transport -> HTTP



Specify Service name and transport for proxy service.
Service name: FixedLengthProxyService
Transport: http
Messaging Req: Text
     Resp: XML






Link this created proxy service with pipeline.
FixedLengthProxyService -> FixedLength_MessageTypePipeline -> FixedLength_MockResponse



Next step is to create nXSD schema to convert flat file of fixed length into XML using native format builder.
FixedFile_MessageTypeService -> Resources -> native format (Right click) -> nXSD schema.




Specify name for nXSD schema
Name: FixedFileToXSD


Choose Type: Fixed Length 


Select sample fixed length file from specified location


In above example we have selected sample file by name FixedLength.txt from desktop location.
C:\Users\Tapan\desktop\FixedLength.txt

Below is content of FixedLength.txt which is having each column of length 42.


Next specify record organization as below
* File contains multiple record instances
* Multiple records are of single type


Specify child element name for Root-Element
Enter Name for element that will represent record: Fixed Length


Next step is to specify a field length by clicking at desired position on ruler.


In above example we have specified 3 fields of length 20,31,42 respectively.


As shown above we can locate field properties. Click on Next


We can see that schema got generated for specified flat file.


Next step is to create stubs and FixedLength_MockResponse proxy service to get some valid static response.






Create Mock Response Service with below specification.
Name: FixedLengthFile_MockResponseProxyService
Transport: local
Service Type: Any XML




Save incoming request in variable called $incomingBody using ‘Assign’ activity.


Save transport user-header value which is coming in $inbound into a variable called ‘$IncomingMessageType’



Next add a ‘If’ condition with logic as below
data ($IncomingMessageType) =”FixedFileLength”



Next add a ‘Replace’ action inside If condition with expression as below

<FinalResponse>
<Code>000</Code>
<Desc>FixedLengthFile Message type tested successfully. </Desc>
<ChangedFileBody> {$body/*: Root-Element} </ChangedFileBody>
</FinalResponse>




Add a Reply node with status ‘with success’




 Add a route node and route incoming request to Mock service.


Next add a nXSD translate node to convert native file into XML, and save the converted XML body into a variable called ‘FixedFileBody’.



Add a insert node in order to send content of $FixedFileBody into mock service.





Next add a ‘Transport Header’ activity and assign a user-header with name and value as below
Direction: outbound-request
Action: set
Name: MessageType
Protocol: http
Value: FixedLengthFile




Deploy service into standalone local weblogic server.



Once deployment is successful, we can locate service in sbconsole.



Next run Fixed_lengthPipeline



A pop up window will get open in which we need to select flat file which we use for testing.



Once the execution of request is success , we can see response as below


We can see that flat file is converted into XML structure and the same we have populated in final response.



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