Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Integration - SOA and metadata simplify development

Updated on September 10, 2021

 This presentation is part of the Services and Connectors Self-Study Course.


A person acting in the role of a PRPC System Architect should not:

  • Create the client software code that allows an external system to interact with a PRPC service

Many integration methods come with components that allow a client application to understand how to connect into PRPC.  For instance, a WSDL file is generated when you create a PRPC Service using SOAP.  This describes the operations, along with inputs and outputs.  Just handoff the WSDL to someone developing the external client, and they can code things up from there.

Most modern software contains code generators.  For instance, VisualStudio.NET can read in a WSDL, automatically generating much of the .NET client code.

  • Define the code that a connector will be calling

If it's a web service, the web service should exist.  If it's a SQL connector, the database table should exist.

  • Define deployment files that a connector uses.

For instance, the Connector Wizard for SOAP uses a WSDL to generate much of the connector code.  The person coding up the external system should be giving you a WSDL file.  In fact, modern software such as VisualStudio.Net should be able to automatically generate a WSDL for you.

 This is no different than PRPC generating a WSDL during execution of the service wizard.

  • Have to understand or be forced to code portions of an organization's integration architecture, which may include an SOA (service oriented architecture).

An understanding of SOA is needed and will allow you to be a productive part of conversations involving integration.  But in most cases, the PRPC System Architect should not have to be involved in low level integration details.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us