Projects:Modularity/Central Repository/it

Contents 1 Servizi del Repository Centrale 1.1 Introduzione 1.2 Detailed description for services to Developers 1.2.1 Register a module 1.2.2 Publish a new version of a module 1.2.3 Update information of a version of a module 1.3 Detailed description for services to Users 1.3.1 Search for Modules 1.3.2 Detailed information of a Version 1.3.3 Get the code of a Module - Version 1.3.4 Scan for Updates 1.3.5 Check Consistency 1.4 Closed Discussion Items

Servizi del Repository Centrale

Introduzione

Il Repository Centrale è un sistem incorporato in Openbravo Forge per fornire servizi collegati ai moduli Openbravo per sviluppatori e utenti.

Per decouple lo sviluppo di Openbravo Forge e i servizi del progetto di Modularità sono progettati per essere operati da Openbravo ERP o dal Forge. The first group of services are architected as web services provided by the Central Repository –so the Forge- and consumed by Openbravo ERP components that are responsible to provide a user interface for them. The second group are services provided directly by the Forge without any dependency on Openbravo ERP.

Services provided by the Central Repository (there is a detailed description in the next section):

• For developers:
  • Register a module: a developer registers a new module in the Central Repository to get global unique identifiers to be used for development (it's required to register a module before starting the module's development).
  • Publish a new version of a module: a module can have different versions in its life cycle. For each of them module owners need to update the information in the Central Repository to make this new version available for users.
  • Update the information of a version of a module: module owners are allowed to modify some information in a version of a module (eg. Extend the compatible versions of a module it depends on).
• For users:
  • Search for modules: from the MMC users can query the Central Repository to get a list of modules that match with user request.
  • Detailed information of a module: from the MMC users can query the Central Repository to get all the information available from a module.
  • Scan for updates of a list of module versions: from the MMC users can request to the Central Repository if there are available updates (newer versions) for all the modules installed in their instances (or just for one of them).
  • Get the code of a module version (to be installed) : for both installing new modules and updating current ones it is needed to get the compressed file (.xob file) that stores module code.
  • Check consistency: from a list of modules version, the Central Repository validate that all of them can be installed together, validating all dependencies.

The integration between Openbravo Forge and the Central Repository is very light:

• every module in the repository is owned by a registered developer in the Forge. The "Register a module" service will require to get developer's username and password to be executed. There is no need to associate a project to a module (it's optional) but it's required to assign it to a registered developer who is the owner and will be allowed to publish versions, link the module to a project, manage privileges for that module, etc.
• a module can be (optionally) linked to a project in the Forge
• when publishing a module installer or upgrader in the Forge (within a project) it will automatically update the Central Repository. If the module was not linked to a project it will be automatically linked in the publishing.
• the other three web services defined (search modules, get module, scan for updates) can be implemented in the Central Repository without any dependency on the Forge.

Detailed description for services to Developers

Services for Developers need to be secured since through them developers will administer their modules. This security need to be managed by the Forge through its standard capabilities (single sign-on, privileges, developers in a project, etc.). So developers need to be registered in the Openbravo Forge to use these services.

Register a module

A developer creates a new module in its Openbravo ERP instance and from the Module Window requests to register it. The request includes some module information. The Central Repository validates the information. If it is ok then it stores the information in the DB and returns a success message confirming the registration that will be managed by the Module Window to be shown to the developer. If it's wrong returns a failure message with a clear explanation of the error and suggestions on how to proceed.

Information provided in the request:

• ModuleID: UUID. This parameter is mandatory and it's automatically generated by Openbravo ERP.
• DB_prefix: string up to 7 ASCII characters. Only alphanumeric characters and underscore (“_”) are allowed. Must begin with an alphabetical character. All alphabetical characters must be uppercase. This parameter is optional.
• Package_name: string up to 255 ASCII characters following Java packaging names rules as described in the Java spec. (names and package names). This parameter is mandatory.
• Name: string up to 60 characters in natural English. Mandatory.
• Description: string up to 255 characters in natural English. Short description of module capabilities. Mandatory.
• Type: one character. 'M' for module, 'P' for packages and 'I' for industry templates. Mandatory.
• User name: developer’s user name in the Openbravo Forge.
• Password: developer’s password in the Openbravo Forge

Validation before performing the registration:

• Username and password match with a registered developer in the Forge.
• All required parameters are provided and match their specific rules.
• ModuleID is not previously registered.
• If DB_prefix is provided it's not previously registered in other module.
• Package_name is not previously registered in other module.

If the validation fails the Service returns an error message with a clear explanation of the error and suggestions on how to solve it (eg. Similar package name or DB_prefix that are not registered yet).

Actions if the validation is successful:

• Save the new module in the Central Repository database. Save audit info for the new module (createdBy, dateCreated)
• Return a success message including all the information in the registered module (ModuleID, DB_prefix, etc.)

Example of declaration of web service in Java:

public Module moduleRegister(Module module, String userName, String password);

WSDL technical detail:

<complexType name="Module">
 <sequence>
   <element name="author" nillable="true" type="xsd:string"/>
   <element name="dbPrefix" nillable="true" type="xsd:string"/>
   <element name="dependencies" nillable="true" type="impl:ArrayOf_tns1_ModuleDependency"/>
   <element name="description" nillable="true" type="xsd:string"/>
   <element name="help" nillable="true" type="xsd:string"/>
   <element name="includes" nillable="true" type="impl:ArrayOf_tns1_ModuleDependency"/>
   <element name="licenseAgreement" nillable="true" type="xsd:string"/>
   <element name="licenseType" nillable="true" type="xsd:string"/>
   <element name="moduleID" nillable="true" type="xsd:string"/>
   <element name="moduleVersionID" nillable="true" type="xsd:string"/>
   <element name="name" nillable="true" type="xsd:string"/>
   <element name="packageName" nillable="true" type="xsd:string"/>
   <element name="type" nillable="true" type="xsd:string"/>
   <element name="updateDescription" nillable="true" type="xsd:string"/>
   <element name="url" nillable="true" type="xsd:string"/>
   <element name="versionNo" nillable="true" type="xsd:string"/>
 </sequence>
</complexType>

<wsdl:message name="moduleRegisterResponse">
  <wsdl:part name="moduleRegisterReturn" type="tns1:Module"/>
</wsdl:message>

<wsdl:message name="moduleRegisterRequest">
  <wsdl:part name="in0" type="tns1:Module"/>
  <wsdl:part name="in1" type="soapenc:string"/>
  <wsdl:part name="in2" type="soapenc:string"/>
</wsdl:message>

<wsdl:operation name="moduleRegister" parameterOrder="in0 in1 in2">
  <wsdl:input message="impl:moduleRegisterRequest" name="moduleRegisterRequest"/>
  <wsdl:output message="impl:moduleRegisterResponse" name="moduleRegisterResponse"/>
</wsdl:operation>

<wsdl:operation name="moduleRegister">
  <wsdlsoap:operation soapAction=""/>
  <wsdl:input name="moduleRegisterRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.ws.erpCommon.openbravo.org" use="encoded"/>
  </wsdl:input>
  <wsdl:output name="moduleRegisterResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://67.202.45.105/openbravo/services/WebService" use="encoded"/>
  </wsdl:output>
</wsdl:operation>

Publish a new version of a module

This service is fully provided through the standard process of publishing files in the Openbravo Forge. A developer logged in the Forge requests to publish a new version of a module he/she is allowed to publish versions. The request includes the .obx file for that module-version that has been generated from an utility in Openbravo ERP. The Central Repository reads the file and validates the information. If it is ok then it stores the information in the DB and returns a success message confirming the new version has been published. If it is wrong returns a failure message with a clear explanation of the error and suggestions on how to proceed.

Information provided in the request (included in the .obx file):

• ModuleID: UUID. Identifies the module of the new version. This parameter is mandatory and it's automatically generated by Openbravo ERP.
• Version_No: string up to 10 numeric characters following the template defined here. This parameter is mandatory.
• Update description: string up to 2000 characters in natural English. Long description of new capabilities included in this version (new features, fixed bugs, etc.). Optional.
• Dependencies: list of all modules this new version depends on. Dependencies are defined by module-version, but only the most relevant part of the version is taken into account (up to major release). Dependencies can be defined for a range of versions. This parameter is mandatory (all modules at least depend on core module). For each dependency the following information is provided:
  • ModuleID: UUID. Identifies the module this new version depends on. This parameter is mandatory and it's automatically generated by Openbravo ERP.
  • Start_Version: string up to 10 numeric characters following the defined template. Identifies the first compatible version of the module it depends on. This parameter is mandatory.
  • End_Version: string up to 10 numeric characters following the defined template. Identifies the last compatible version of the module it depends on. This parameter is optional.

Updateable information in a module might change from time to time. To keep consistent information when a new version is created all these fields are copied into it. When a new version is published the module is updated with the information in the latest version. So this information is also provided in the process of publishing a new version:

• Name: string up to 60 characters in natural English. Mandatory.
• Description: string up to 255 characters in natural English. Short description of module capabilities. Mandatory.
• Help: string up to 2000 characters in natural English. Long description of module capabilities. Optional.
• License_type: [MPL, Apache, BSD, …, other]. Optional
• License_agreement: string up to 2000 characters in natural English. The user will accept this agreement when installing. Optional
• Author: string up to 2000 characters in natural English. Optional
• URL: string up to 300 characters. Module URL’s. Optional

Validation before performing the publishing:

• All required parameters are provided and match their specific rules.
• All the pairs ModuleID – Start_Version and ModuleID – End_Version exists in the Central Repository database.
• ModuleID exists and last published Version_No is lower than new one (only forward versions are allowed)
• If the new version is a minor release (only the last part of the Version_No increases) changes in dependencies are not allowed except extending the compatibility of existing dependencies by providing higher values of End_Version in some of them.
• CRC validation of XOB file (nice to have).

If the validation fails the Service returns an error message with a clear explanation of the error and suggestions on how to solve it (eg. You can not change the dependencies in a minor release).

Actions if the validation is successful:

• Calculate a ModuleVersionID, it will be the ID that return the "search modules" service and it will be the ID passed to "get module" and "module detail" services.
• Save the new version in the Central Repository database. Save audit info for the new version (createdBy, dateCreated)
• Save the XOB file attached to it.
• Update all updateable information in a module (Name, Description, Help, License_type, License_agreement, Author, URL) with the new values in the version. Also update the Version_No in the module with the latest value.
• Return a success message including all the information in the new version published.

Update information of a version of a module

This service is fully provided through the Openbravo Forge. A logged in the Forge developer requests to publish a new version of a module he/she is allowed to modify. The request includes the .obx file for that module-version that has been generated from an utility in Openbravo ERP. The only information he/she can change is to extend the compatibility of version in modules it depends on. The request includes information of the version included in the .obx file. The Central Repository validates the information. If it is ok then it stores the information in the DB and returns a success message confirming the version has been updated. If it is wrong returns a failure message with a clear explanation of the error and suggestions on how to proceed.

Information provided in the request:

• ModuleID: UUID as defined here. Identifies the module this new version depends on. This parameter is mandatory and it is automatically generated by Openbravo ERP.
• Version_No: string up to 10 numeric characters following the template defined here. This parameter is mandatory. The pair ModuleID and VersionNo identifies one module version and will not be updated.
• Dependencies: list of all modules this new version depends on. This parameter is mandatory. For each dependency the following information is provided:
• End_Version: string up to 10 numeric characters following the template defined here. Identifies the last compatible version of the module it depends on. This parameter is mandatory.

Validation before performing the update:

• All required parameters are provided and match their specific rules.
• All the ModuleID in the dependencies list exist in the dependency list of the version.
• All the pairs ModuleID – End_Version exist in the Central Repository database.

If the validation fails the Service returns an error message with a clear explanation of the error and suggestions on how to solve it (eg. The dependency you want to extend does not exist in the current version).

Actions if the validation is successful:

• Update the dependencies with the provided values. Save audit info for the new version (updatedBy, dateUpdated)
• Save the XOB file attached to it.
• Return a success message including all the information in the version updated.

Detailed description for services to Users

Services to Users do not need to be secured since it is public information (perhaps in the future it will be required for modules in the AppExchange). All these services have to be implemented as web services and they are not directly operated by the User but by the Module Manager Console (MMC) in Openbravo ERP. These services should support multi-language (TBD) so information in the MMC is shown in the language of the user or English if not available.

Search for Modules

From the MMC in Openbravo ERP a user queries the Central Repository with a filtering criteria and a list of installed modules. The Central Repository executes that query in its database and returns a list of light module-version objects that match the criteria less the installed modules. The MMC gets the list of objects and shows them to the user.

Information provided in the request:

• Word (text) to be found in the module description
• List of installed modules (Array of String with ModuleID's)

The service gets this value and performs a query in its database to get the last version of all modules in the Central Repository where their description contains the word (text) in the request.

A light module-version object includes the next attributes:

• ModuleVersionID of the last version for that module.
• Name
• Description
• Help
• Type
• License_type
• License_agreement
• Author
• URL
• Version_No
• Update description

Example of declaration of web service in Java:

public SimpleModule[] moduleSearch(String word, String[] exclude);

WSDL technical detail:

<complexType name="SimpleModule">
  <sequence>
    <element name="author" nillable="true" type="xsd:string"/>
    <element name="description" nillable="true" type="xsd:string"/>
    <element name="help" nillable="true" type="xsd:string"/>
    <element name="licenseAgreement" nillable="true" type="xsd:string"/>
    <element name="licenseType" nillable="true" type="xsd:string"/>
    <element name="moduleID" nillable="true" type="xsd:string"/>
    <element name="moduleVersionID" nillable="true" type="xsd:string"/>
    <element name="name" nillable="true" type="xsd:string"/>
    <element name="type" nillable="true" type="xsd:string"/>
    <element name="updateDescription" nillable="true" type="xsd:string"/>
    <element name="url" nillable="true" type="xsd:string"/>
    <element name="versionNo" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>

<complexType name="ArrayOf_tns1_SimpleModule">
  <complexContent>
    <restriction base="soapenc:Array">
      <attribute ref="soapenc:arrayType" wsdl:arrayType="tns1:SimpleModule[]"/>
    </restriction>
  </complexContent>
</complexType>

<wsdl:message name="moduleSearchResponse">
  <wsdl:part name="moduleSearchReturn" type="impl:ArrayOf_tns1_SimpleModule"/>
</wsdl:message>

<wsdl:message name="moduleSearchRequest">
  <wsdl:part name="in0" type="soapenc:string"/>
  <wsdl:part name="in1" type="impl:ArrayOf_xsd_string"/>
</wsdl:message>

<wsdl:operation name="moduleSearch" parameterOrder="in0 in1">
  <wsdl:input message="impl:moduleSearchRequest" name="moduleSearchRequest"/>
  <wsdl:output message="impl:moduleSearchResponse" name="moduleSearchResponse"/>
</wsdl:operation>

<wsdl:operation name="moduleSearch">
  <wsdlsoap:operation soapAction=""/>
  <wsdl:input name="moduleSearchRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.ws.erpCommon.openbravo.org" use="encoded"/>
  </wsdl:input>
  <wsdl:output name="moduleSearchResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://67.202.45.105/openbravo/services/WebService" use="encoded"/>
  </wsdl:output>
</wsdl:operation>

Detailed information of a Version

From the MMC in Openbravo ERP a user requests detailed information of a specific version he/she is interested in. The Central Repository executes a query in its database and returns a full module-version object. The MMC gets the object and shows it to the user.

Information provided in the request:

• ModuleVersionID

The service gets this value and performs a query in its database to get all the information related to that module-version.

A full module-version object includes the next attributes:

• ModuleVersionID of the last version for that module.
• ModuleID
• DB_prefix
• Package_name
• Name
• Description
• Help
• Type
• License_type
• License_agreement
• Author
• URL
• Version_No
• Update description
• Dependencies represented with a list of module-dependency objects.
• Includes represented with a list of module-dependency objects.

A module-dependency object includes the next attributes:

• ModuleVersionID
• start_version
• end_version
• module_dependant_id
• module_dependant_name

Example of declaration of web service in Java:

public Module moduleDetail(String moduleVersionID)

WSDL technical detail:

<complexType name="ModuleDependency">
  <sequence>
    <element name="moduleID" nillable="true" type="xsd:string"/>
    <element name="moduleName" nillable="true" type="xsd:string"/>
    <element name="moduleVersionDependencyID" nillable="true" type="xsd:string"/>
    <element name="moduleVersionID" nillable="true" type="xsd:string"/>
    <element name="versionEnd" nillable="true" type="xsd:string"/>
    <element name="versionStart" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>

<complexType name="Module">
  <sequence>
    <element name="author" nillable="true" type="xsd:string"/>
    <element name="dbPrefix" nillable="true" type="xsd:string"/>
    <element name="dependencies" nillable="true" type="impl:ArrayOf_tns1_ModuleDependency"/>
    <element name="description" nillable="true" type="xsd:string"/>
    <element name="help" nillable="true" type="xsd:string"/>
    <element name="includes" nillable="true" type="impl:ArrayOf_tns1_ModuleDependency"/>
    <element name="licenseAgreement" nillable="true" type="xsd:string"/>
    <element name="licenseType" nillable="true" type="xsd:string"/>
    <element name="moduleID" nillable="true" type="xsd:string"/>
    <element name="moduleVersionID" nillable="true" type="xsd:string"/>
    <element name="name" nillable="true" type="xsd:string"/>
    <element name="packageName" nillable="true" type="xsd:string"/>
    <element name="type" nillable="true" type="xsd:string"/>
    <element name="updateDescription" nillable="true" type="xsd:string"/>
    <element name="url" nillable="true" type="xsd:string"/>
    <element name="versionNo" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>

<wsdl:message name="moduleDetailRequest">
  <wsdl:part name="in0" type="soapenc:string"/>
</wsdl:message>

<wsdl:message name="moduleDetailResponse">
  <wsdl:part name="moduleDetailReturn" type="tns1:Module"/>
</wsdl:message>

<wsdl:operation name="moduleDetail" parameterOrder="in0">
  <wsdl:input message="impl:moduleDetailRequest" name="moduleDetailRequest"/>
  <wsdl:output message="impl:moduleDetailResponse" name="moduleDetailResponse"/>
</wsdl:operation>

<wsdl:operation name="moduleDetail">
  <wsdlsoap:operation soapAction=""/>
  <wsdl:input name="moduleDetailRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.ws.erpCommon.openbravo.org" use="encoded"/>
  </wsdl:input>
  <wsdl:output name="moduleDetailResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://67.202.45.105/openbravo/services/WebService" use="encoded"/>
  </wsdl:output>
</wsdl:operation>

Get the code of a Module - Version

From the MMC in Openbravo ERP a user requests to install a module-version he/she has previously found. The Central Repository returns the XOB file for that module-version. The MMC gets the file and installs it into the user instance.

Information provided in the request:

• ModuleVersionID

The service returns the XOB file for that ModuleVersionID.

Example of declaration of web service in Java:

public byte[] getModule(String moduleVersionID)

WSDL technical detail:

<wsdl:message name="getModuleRequest">
  <wsdl:part name="in0" type="soapenc:string"/>
</wsdl:message>

<wsdl:message name="getModuleResponse">
  <wsdl:part name="getModuleReturn" type="soapenc:base64Binary"/>
</wsdl:message>

<wsdl:operation name="getModule" parameterOrder="in0">
  <wsdl:input message="impl:getModuleRequest" name="getModuleRequest"/>
  <wsdl:output message="impl:getModuleResponse" name="getModuleResponse"/>
</wsdl:operation>

<wsdl:operation name="getModule">
  <wsdlsoap:operation soapAction=""/>
  <wsdl:input name="getModuleRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.ws.erpCommon.openbravo.org" use="encoded"/>
  </wsdl:input>
  <wsdl:output name="getModuleResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://67.202.45.105/openbravo/services/WebService" use="encoded"/>
  </wsdl:output>
</wsdl:operation>

Scan for Updates

From the MMC in Openbravo ERP a user requests for available updates for some (one, many, all) the modules he/she has installed in his/her instance. The Central Repository executes a query in its database and returns a list of light module-version objects that are newer versions of the module-versions provided. All the modules version contained in the list of updates will be compatible with themselves and with installed modules version, this means that all the modules version returned in list of updates can be installed without any problem of dependencies. The MMC gets the list of objects and shows them to the user.

Information provided in the request:

• HashMap of pairs ModuleID’s with its VersionNo to scan for updates

The service gets this list and performs a query in its database to get the newest version for each of them, if any

Example of declaration of web service in Java:

public SimpleModule[] moduleScanForUpdates(HashMap<String,String> moduleIdInstalledModules);

WSDL technical detail:

<complexType name="SimpleModule">
  <sequence>
    <element name="author" nillable="true" type="xsd:string"/>
    <element name="description" nillable="true" type="xsd:string"/>
    <element name="help" nillable="true" type="xsd:string"/>
    <element name="licenseAgreement" nillable="true" type="xsd:string"/>
    <element name="licenseType" nillable="true" type="xsd:string"/>
    <element name="moduleID" nillable="true" type="xsd:string"/>
    <element name="moduleVersionID" nillable="true" type="xsd:string"/>
    <element name="name" nillable="true" type="xsd:string"/>
    <element name="type" nillable="true" type="xsd:string"/>
    <element name="updateDescription" nillable="true" type="xsd:string"/>
    <element name="url" nillable="true" type="xsd:string"/>
    <element name="versionNo" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>

<wsdl:message name="moduleScanForUpdatesRequest">
  <wsdl:part name="in0" type="apachesoap:Map"/>
</wsdl:message>

<wsdl:message name="moduleScanForUpdatesResponse">
  <wsdl:part name="moduleScanForUpdatesReturn" type="impl:ArrayOf_tns1_SimpleModule"/>
</wsdl:message>

<wsdl:operation name="moduleScanForUpdates" parameterOrder="in0">
  <wsdl:input message="impl:moduleScanForUpdatesRequest" name="moduleScanForUpdatesRequest"/>
  <wsdl:output message="impl:moduleScanForUpdatesResponse" name="moduleScanForUpdatesResponse"/>
</wsdl:operation>

<wsdl:operation name="moduleScanForUpdates">
  <wsdlsoap:operation soapAction=""/>
  <wsdl:input name="moduleScanForUpdatesRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.ws.erpCommon.openbravo.org" use="encoded"/>
  </wsdl:input>
  <wsdl:output name="moduleScanForUpdatesResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://67.202.45.105/openbravo/services/WebService" use="encoded"/>
  </wsdl:output>
</wsdl:operation>

Check Consistency

From the MMC in Openbravo ERP a user requests for checking the consistency of a set of new modules to install and/or update in his/her particular instance, taking into account the modules that the instance has installed. The Central Repository executes a query in its database and checks all the dependencies and includes of modules installed in the client, new modules to install and modules to update. There might be more than one combination of module-versions that meets all dependencies and includes. In that case the Central Repository executes an algorithm to find the most "updated" combination: one combination is more "updated" than other when it includes newer versions for higher priority modules (priority is first core, then Industry Templates, then packs and last plain modules) or it includes more updated versions for equal priority modules.

The Central Repository returns an object including an array of full module-version objects to install, an array of full module-version objects to update, an array of user messages for eventual errors because of broken dependencies, and a boolean to know if a valid configuration have been found. With the information returned, the MMC can do a get of all the module-versions to install/update them or return a user message explaining why he/she can not install/update those modules.

Information provided in the request:

• HashMap of pairs ModuleID’s with its VersionNo to scan for updates
• Array of ModuleVersionID’s of modules to install.
• Array of ModuleVersionID’s of modules to update.

The service gets those lists and process all the data to return a ModuleInstallDetail, which contains:

• Array of full module-version object with modules to install.
• Array of full module-version object with modules to update.
• Array of String with dependency errors.
• Boolean valid_combination, true if a valid combination is found.

Example of declaration of web service in Java:

public ModuleInstallDetail checkConsistency(HashMap<String,String> versionIdInstalled, String[] versionIdToInstall, String[] versionIdToUpdate);

WSDL technical detail:

<complexType name="ModuleDependency">
  <sequence>
    <element name="moduleID" nillable="true" type="xsd:string"/>
    <element name="moduleName" nillable="true" type="xsd:string"/>
    <element name="moduleVersionDependencyID" nillable="true" type="xsd:string"/>
    <element name="moduleVersionID" nillable="true" type="xsd:string"/>
    <element name="versionEnd" nillable="true" type="xsd:string"/>
    <element name="versionStart" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>

<complexType name="Module">
  <sequence>
    <element name="author" nillable="true" type="xsd:string"/>
    <element name="dbPrefix" nillable="true" type="xsd:string"/>
    <element name="dependencies" nillable="true" type="impl:ArrayOf_tns1_ModuleDependency"/>
    <element name="description" nillable="true" type="xsd:string"/>
    <element name="help" nillable="true" type="xsd:string"/>
    <element name="includes" nillable="true" type="impl:ArrayOf_tns1_ModuleDependency"/>
    <element name="licenseAgreement" nillable="true" type="xsd:string"/>
    <element name="licenseType" nillable="true" type="xsd:string"/>
    <element name="moduleID" nillable="true" type="xsd:string"/>
    <element name="moduleVersionID" nillable="true" type="xsd:string"/>
    <element name="name" nillable="true" type="xsd:string"/>
    <element name="packageName" nillable="true" type="xsd:string"/>
    <element name="type" nillable="true" type="xsd:string"/>
    <element name="updateDescription" nillable="true" type="xsd:string"/>
    <element name="url" nillable="true" type="xsd:string"/>
    <element name="versionNo" nillable="true" type="xsd:string"/>
  </sequence>
</complexType>

<complexType name="ModuleInstallDetail">
  <sequence>
    <element name="dependencyErrors" nillable="true" type="impl:ArrayOf_xsd_string"/>
    <element name="modulesToInstall" nillable="true" type="impl:ArrayOf_tns1_Module"/>
    <element name="modulesToUpdate" nillable="true" type="impl:ArrayOf_tns1_Module"/>
    <element name="validConfiguration" type="xsd:boolean"/>
  </sequence>
</complexType>

<wsdl:message name="checkConsistencyResponse">
  <wsdl:part name="checkConsistencyReturn" type="tns1:ModuleInstallDetail"/>
</wsdl:message>

<wsdl:message name="checkConsistencyRequest">
  <wsdl:part name="in0" type="apachesoap:Map"/>
  <wsdl:part name="in1" type="impl:ArrayOf_xsd_string"/>
  <wsdl:part name="in2" type="impl:ArrayOf_xsd_string"/>
</wsdl:message>

<wsdl:operation name="checkConsistency" parameterOrder="in0 in1 in2">
  <wsdl:input message="impl:checkConsistencyRequest" name="checkConsistencyRequest"/>
  <wsdl:output message="impl:checkConsistencyResponse" name="checkConsistencyResponse"/>
</wsdl:operation>

<wsdl:operation name="checkConsistency">
  <wsdlsoap:operation soapAction=""/>
  <wsdl:input name="checkConsistencyRequest">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.ws.erpCommon.openbravo.org" use="encoded"/>
  </wsdl:input>
  <wsdl:output name="checkConsistencyResponse">
    <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://67.202.45.105/openbravo/services/WebService" use="encoded"/>
  </wsdl:output>
</wsdl:operation>

Closed Discussion Items

ICI: how to implement support for multi-language in modularity? It seems that the search for modules service should show module information (name, description, help) in the language of the user if available, but it would be odd that when installing the same information is shown in English (because the .obx does not include the translations). Other problem is that modules for translations to other languages other than English are modules and need to be declared in English (so they need a translation but in a different module?). So perhaps translations for a module (at least module information) should be included in the .obx file, although it is also a problem because it should be done by a different team from the one who developed the module) -> It is solved because modules are defined in a native language. For further details go to Translation Modules spec.

Category: Italian