porting datamodel from SOA Suite to OSB - part 1

In SOA Suite 11g, you can use MDS to manage and centralize your datamodel. if you have a big project ( if true, most probably you are using AIA or at least your own methodology ), perhaps mds would have a wide range of files that composed with wsdl and xsd files. To connect these files with each other, you can use either one of relative path or "oramds:/XXX/YYY" approach. it is recommended to use relative paths in whole of the datamodel. although this suggestion is very imported, you can not some times use this relative path approach, especially in requestorABCS or providerABCS (these are the connector services from/to the systems). in development time and time runtime, this ABCS wsdl files' are the points that entering to MDS. so you have to use "oramds" key word.

it's not important where or how much you use the keyword (oramds) in your datamodel with while using SOA Suite, but if you want to use this datamodel out of the world , like OSB maybe, you have to convert these files to relative paths. this convertion must be done by a task which gets datamodel as an input and give the output that contains all the paths as relative. you can not do it ones, when you have an on going environments which one of is SOA Suite. you have to repeat it when some thing added/removed/altered in MDS. to do this, you can use this task (or modified one) to change all the (oramds)es with relative ones.

  


 basedir ${basedir}
 
 
 
 
  
   
  
 
 
 
 
 

  
   
    
   
   
    Replacing "oramds" in @{file}
    
     
    
   
  

  
   
    
   
   
    Removing "http:binding" in @{file}
    
     
    
   
  
  
  

 

 
  
  
   
   
  

  
   
   
    Removed "http:binding" in ${httpBindingNameInWsdl} in file ${file}

    
     
    
    
     
     
      Removing "http:binding" in ${httpServiceBindingNameInWsdl} in file ${file}
      
     
    
    
     
    
   
   
    Nothing to be removed  in file ${file}
   
  

 

 
  

  
  countedSlashString = ${countedSlashString}

  
   
  
 
 
  
  
   
    
    
   
  
  
  
 

 
  
   
  
  
   
  
 

you can simple import this jar generated by the task with osb console. follow this way , “create resource ->Bulk -> Zipped Resources” at Osb sbconsole

as an information; OSB has more strict control then SOA Suite, because of this, you may have some other import problems. in may faced case, some application wsdls are generated with one error in design time a couple of years ago (http binding part has an invalite data, and have to be removed in wsdls). so I have write a complex xmltask to find and remove http binding , and this binding from service part. you can get an idea how to do this with task removeHttpBindingPartAndItsServicePort mentioned above.