Loading...
 

Service Registration Wizard FAQ Help

This FAQ groups common questions about the SSE Service Registration Wizard and provides answers for them.

Questions

  1. Is any validation performed on the WSDL, XSD and XSL files provided when using a custom interface?
  2. When using a custom interface, are the WSDL and XSD files used by the SSE during the service execution? For what?
  3. When using a default interface, are the WSDL and XSD files used by the SSE during the service execution or just for the workflow generation/compilation?
  4. My workflow is receiving an empty or almost empty message from the SSE Portal! What could be the reason?
  5. Are the stylesheets that are automatically generated by the SSE for default operations (i.e. Search) specific to those operations or can they be used also for other operations (i.e. Order)?
  6. Which XSLT engine is used for stylesheet processing?
  7. During the SSE migration from version 5.2 to 5.3, which introduced the Service Registration Wizard as the single way of registering a service, all services were converted to default interfaces, even if they were using custom workflows. Should I have any special concerns when updating my service for the first time after the migration?
  8. Is the SSE 5.3 backwards-compatible with the SSE 5.2?
  9. The SSE reports my workflow compilation as finished and I receive the e-mail notifying me that the registration is finished. Everything seems correct but at some point during the service execution I get an SSE Portal error and on the BPEL Console I see that the compilation was not succesful as reported. What can I do?
  10. Is there another place with more information on how to go about updating an old service (created before SSE 5.3) in order for it to work in the new version of the SSE?
  11. I have transferred my service from the Test Portal to the Operational Portal. As far as I can see, the service has been registered in exactly the same way, but on the Operational Portal the Search operation does not work. What is wrong?

Answers

Question: Is any validation performed on the WSDL, XSD and XSL files provided when using a custom interface?
Answer 

No.

However, as a good practice, we recommend the use of a good XML editor such as XMLSpy in order to create, edit and validate all SSE XML interface files.

Question: When using a custom interface, are the WSDL and XSD files used by the SSE during the service execution? For what?
Answer  During service execution, the XSL is the essential file. The XSD is used in conjunction with it to generate the BPEL workflow input message. The WSDL file is not directly used but its "targetNamespace" attribute must match the one on the XSL, which is also true for the XSD. The "targetNamespace" attribute is used during the XSLT transformation that the XSL undergoes.
Question: When using a default interface, are the WSDL and XSD files used by the SSE during the service execution or just for the workflow generation/compilation?
Answer 

Regarding the service execution, the process is similar to that of a custom interface (see previous question).

Regarding the compilation, the WSDL is the most important file although in practice you can look at the WSDL and the XSD as one single logical file since the former refers to the latter. The important information that is taken from the WSDL is the service name, the SOAP location to point to and the namespace.

The XSL is not used for the workflow compilation.

Question: My workflow is receiving an empty or almost empty message from the SSE Portal! What could be the reason?
Answer  This is a common problem and it normally means that something is not correct with your XSL, preventing a successful matching of one or more templates. Things to check are the template names and namespaces (typos and operation type - synchronous or asynchronous) against the SSE ICD and also the targetNamespace attribute of the XSL which must match what is on the XSD and WSDL.
Question: Are the stylesheets that are automatically generated by the SSE for default operations (i.e. Search) specific to those operations or can they be used also for other operations (i.e. Order)?
Answer 

The automatically generated stylesheets are specific to the operations they are associated to and thus cannot be associated to the other operations without changing them. For example, if one chooses a Catalogue interface with Search operation selected, a stylesheet is generated and associated to the Search operation. This stylesheet cannot be used as the custom stylesheet associated to a Custom Order.

Furthermore, the automatically generated stylesheets are also specific to the operation type - synchronous or asynchronous, i.e. you cannot use a stylesheet generated for a default synchronous order for a default asynchronous order.

Question: Which XSLT engine is used for stylesheet processing?
Answer  Apache Xalan, version 2.2.
Question: During the SSE migration from version 5.2 to 5.3, which introduced the Service Registration Wizard as the single way of registering a service, all services were converted to default interfaces, even if they were using custom workflows. Should I have any special concerns when updating my service for the first time after the migration?
Answer 

Yes.

First of all, you should not click "Update Service" before changing the interface of your service from Default to Custom, on Step 1. Clicking "Update Service" before changing the interface will cause the SSE to generate a default workflow for your service, breaking it. However, your custom workflow will not be overwritten, as the SSE will generate the new workflow with a different name. So, if for any reason you click "Update Service" before changing the interface of your service on Step 1, you can still correct the situation by re-associating the operation with your custom workflow.

Secondly, you should be aware that if you wish to follow the previous version of the SSE ICD (1.5), by using interface files (WSDL, XSD and XSL) developed based on that version (1.4 schemas), you should always use a Custom interface and you will have to develop or reuse your own workflow. This can be easily done with a BPEL editor (e.g. JDeveloper) and/or using other workflows obtained from the BPEL Console as a basis.
This "workaround" is necessary because the new version of the SSE, 5.3, generates interface files and workflows based on the new version of the ICD (1.6).

Note that these concerns do not apply if you do not want to change your service - services that worked before the migration also work after it -, but they do apply if you have a service that was working before the migration on the SSE Test Portal and now you want to transfer it to the Operational Portal. If this is your case, you should contact us so that the best strategy can be planned.

Question: Is the SSE 5.3 backwards-compatible with the SSE 5.2?
Answer 

No, in the sense that if you use interface files (WSDL, XSL and XSD) based on SSE 5.2 (ICD 1.5, schemas 1.4) to register a default interface service, it won't work. This is because the SSE will generate workflows based on ICD 1.6, schemas 1.6.

Yes, in the sense that if you ensure certain conditions you can still use interface files based on ICD 1.5.

The migration ensured that services working before it would work also after it but, as explained in the previous item, this is only true until you try to update your service for the first time and you should be very careful when doing so.

To use ICD 1.5 based interface files, the workflow also needs to be ICD 1.5 based and thus you need to either develop one or take one which was working previously (normally this is the case when you are transferring a service from the Test Portal to the Operational Portal). It is also mandatory for you to use a Custom interface.

Finally, you need to make sure that your backend (e.g. TOOLBOX) is aligned with the SSE/BPEL part of your service (i.e. ICD 1.5 SSE/BPEL -> ICD 1.5 TOOLBOX or ICD 1.6 SSE/BPEL -> ICD 1.6 TOOLBOX).

Question: The SSE reports my workflow compilation as finished and I receive the e-mail notifying me that the registration is finished. Everything seems correct but at some point during the service execution I get an SSE Portal error and on the BPEL Console I see that the compilation was not succesful as reported. What can I do?
Answer 

This is a rare event. Normally the SSE is able to detect all compilation errors and report the compilation as failed both on the Portal and via e-mail. When you find this situation, you can go to the BPEL Console, log in, click "BPEL Processes" and "Clear WSDL cache". Then you can try to re-register your service and re-compile your workflow. This time the compilation should be reported as successful and be successful indeed.

If, on the contrary, this still does not solve the problem, you should contact us.

Question: Is there another place with more information on how to go about updating an old service (created before SSE 5.3) in order for it to work in the new version of the SSE?
Answer 

Yes.

The SSE also has an infocenter page dedicated to this. You can see it here.

Question: I have transferred my service from the Test Portal to the Operational Portal. As far as I can see, the service has been registered in exactly the same way, but on the Operational Portal the Search operation does not work. What is wrong?
Answer 

This is a common occurence, especially for default search interface (EOLI, HMA, ...) services that use the WebMapViewer with the default configuration and that have been registered on the Test Portal some time ago, when the running version of the SSE was different.

The common cause for the problem in this case is the GML version that the SSE assumes for default search interface operations and that the WebMapViewer assumes in its default configuration. In particular, the SSE assumes GML 2.1.2 while the WebMapViewer assumes 3.1.1 . To solve this, the service on the Operational Portal needs to be changed as follows:

- on Step 2 of the Service Registration Wizard, change to "use WebMapViewer with custom configuration"
- on Step 3, on the bottom right corner, click Load on the appropriate line (Search, GetRecords, ...)
- on the WebMapViewer control widget on the right, go to tab Configurator->2 and change the GML Version from 3.1.1 to 2.1.2
- click Save on the appropriate line (Search, GetRecords, ...)
- click Update