3 Replies Latest reply on Jul 12, 2019 10:00 AM by Martien van den Akker

    network downloads disabled

    alex k.



      when I try to deploy a module to the OSB I'm getting the following message:


      Could not load resource "https://xyzxyz:443/artifactory/qwert/my_schema.xsd" (network downloads disabled).. null


      The artifactory resides on a second machine and the XSD is part of a WSDL.


      Any idea on what has to be configured to make the deployment work is truly appreciated.


      Best regards

      - Alex

        • 1. Re: network downloads disabled
          Martien van den Akker

          HI Alex,


          When you import a WSDL into OSB, it will download all the artefacts (xsd's, referenced wsdls), that the particular wsdl is depended on, into the project. OSB does this (I believe) partly to prevent having to rely on external resources for consistency of the project. And I think that this is really one of the reasons why. Another reason is caching: having all the artefacts in memory makes the OSB incredibly fast. I think this is also the reason why OSB has no support for the SOASuite MDS: you can't reference artefacts using the oramds:/ protocol.


          Apparently you have created or edited this wsdl within the OSB project to reference this xsd.


          If I read it correctly then you reference it from Artifactory. Actually, I don't think that Artifactory or Nexus are meant for that. In those tools you can configure all kinds of authorizations. That can be changed in a way that it breaks your OSB implementation. By referencing artefacts from an external repository, introduces a dependency with it. And that requires the same level of availability for that repository as for OSB. I think you shouldn't do that. Lastly, you should think about the development lifecycle for those artifacts to prevent that you change an xsd for Dev, that Production depends on.


          How to solve this? Well, to be in line with OSB architecture: move the XSD to the Schemas folder within your OSB project, or create a separate MDS OSB project for artefacts that you would put in the MDS in SOASuite. At one of our customers we had an ANT script that copied all our MDS Working Copy to an OSB project. So that we had only one place we edited our shared artefacts. That MDS project you can deploy together with your main project.



          • 2. Re: network downloads disabled
            alex k.

            Hi Martien,


            thanks for your explanations. We are aware of the fact that referencing artifacts from an external repository requires the repository to have the same availability as our system. Nevertheless we'd like to share some of our artifacts with our customers (WSDLs, XSDs) on a dedicated server and use exactly the same files in OSB.

            I tried "curl" to retrieve the artifact from the console on our developement server, so the Artifactory configuration is not the problem. All that led me to the conclusion that it could simply be a configuration problem in Weblogic Server, but I can't find the right screw to adjust.


            Unfortunately your suggested solution (MDS) is not an option, because even though I placed my question in the SOA Suite section, we actually have only an OSB server running. I might consider implementing some kind of action as part of the deployment which copies files from Artifactory into the project, if no other solution comes up...



            Best regards

            - Alex

            • 3. Re: network downloads disabled
              Martien van den Akker

              Hi Alex,


              As explained, OSB can't use the SOA Suite MDS. So not an option actually.

              But in that line: I understand the desire to have one definition of the same artefact. However, following the OSB architecture, it is not recommended to do it the way you do.


              And, there is another thought. That is actually comparable with creating test-cases in SoapUI/ReadyAPI/Postman/etc.

              Yes, you use a WSDL that is also used by other services and is implemented by a particular service that you call. The WSDL is the contract you agreed with your service provider. You base your implementation on that particular version of the WSDL (and referenced XSDs). The Service provider can change it, but you based your implementation on that one. He should deliver you a new version and then you can change your service. If you would have it centrally stored, then you can change that one, but it is less obvious that you should retest and maybe change your OSB service.


              So, what I would do, is put the external WSDLs and artefacts in a separate folder in your version control system. That's where you maintain those. Then create a ServiceBus project per category, per external service provider, etc. And either have a subversion-reference, or an ANT script that copies those wsdl into the particular ServiceBus project. And then deploy that SB project with your configuration. Also, for the potential other services you can deploy the wsdl's from the same folder to Artifactory.


              That way you can create a way of working that allows you to maintain the artifacts at one place, while deploy them redundantly to the OSB as it likes.


              Or store the WSDLs in a ServiceBus project, define that as  your single-point-of-truth and reference the WSDLs from the Service Bus project in your other apps.

              But, actually I would not recommend that. Although I do understand your considerations, I would recommend you to eliminate the dependencies based on wsdl's as much as possible, by deploying the WSDLs in the project it actually uses. But do so in a way that you can recognize the artifacts as being imported from an external party (and is not to be maintained by you).