VS .NET Database Edition

I think the DB Professional edition of VS .NET is a great tool to help release test- and production-ready projects in a way similar to releasing SAP transports. I’m using this for a handful of applications to maintain source code control in VSS.

VS .NET Database edition lets you import the entire test database schema into a VS project and perform schema comparisons between any combination of: VS project, test db, and production db.

The general process I follow is:
1. Check out code modules required for change (may include client, web app, or db items).
2. Comment changes with issue number assigned.
3. Release to test environment (keep code checked out).
4. Have functional team test the corrections.
5. Request release to production environment.
6. Check code back into VSS and provide issue number and brief description as comment.

My solution contains both the Database project and the Web application project.

The initial DB schema is designed in SQL server manager and imported into VS .NET Database project.

After the initial import, any alterations are done within the VS .NET UI.

I can perform a schema comparison between the code and the test db.

Results of schema comparison:

From here, you can push your database schema changes to the target database.

Configuring a UDDI Registry for SAP Web Services

When designing your internal UDDI registry, planning is key.  There are a lot of posts about using UDDI but most all of them show end results too generic for immediate use.  Because it was so difficult to find a good template design from which to start, I'm writing this.


UDDI Provider Name
The UDDI specification is quite generic.  The businessEntity element (MS UDDI "Provider") can be configured to represent a user, a development team, a machine name, or something else entirely.  To quote the Microsoft UDDI Guide: "The most important aspect of choosing a provider construct is consistency."

After much contemplation and testing, I found that the most logical and useful Provider would be the root domain name of the host test server.  (Example: www-test.intra.net)  

• In this way, multiple web services can be listed under a single Provider.
• If the owner changes hands, it's simple to reassign the Provider to someone else.
• When a WSDL is retrieved for development, it is initially pointing to a non-production system.  Dynamic web references make it easy to point to a production system using an easy-to-remember cross reference (in this case: remove "-test" from the domain name).

SAP NetWeaver 7.0 eHP1

There are a handful of good blogs out there describing how to create the web service definition in SAP NetWeaver, so I won't go into too much detail.  Here are the important things I learned:

• Create your Service Definition around a function GROUP for the biggest benefit.  This gives you multiple operations per service.
• Keep the "Deploy Service" checkbox checked to auto-generate the configuration in SOA Manager.  But this is only valid for the development system because...
• The SOA Manager configuration is no longer transportable via CTS!  This was an eye-opener.  At first I was upset, then distraught, and finally impressed.  This is a great design, but it means you must create your SOA Manager configuration(s) for web services in each system after you transport the Service Definition.  And although not a strict requirement, I suggest that you name the service and endpoints exactly the same so that they have the same SICF path to the endpoint.  This allows the consumer to change systems with ease.

Assuming a three-system landscape (development, quality, and production), you'll find that the WSDL will be different for each system in which the SOA Manager configuration is created. (A unique GUID is assigned at the time of create.) This causes issues only with the WSDL. You can't change just the root domain name to point to the WSDL for another system; instead you need a completely new URL.

But that's okay! My suggestion: only publish the WSDL of your quality system into the UDDI registry. This still meets the requirement set forth earlier: publish the test host server. And it will also allow other (non-SAP) developers access to the WSDL. (This was useful because, in our case, these users already existed in our quality system as a copy of production. In our development system, we would have had to create all of these non-SAP users just to access WSDLs.)

Finally, here is an example of a similar document I put together for release across our IT teams. As mentioned, it is important for all web service publishers to follow the same naming convention when publishing to the UDDI registry. I believe the conventions and best practices below allow for all the search requirements as well as the flexibility in describing and documenting your web services.


Sample Naming Conventions

Field	Rules to Follow When Supplying this Value	Example
Provider	Root domain name of TEST server at which the web service resides.	www-q15s.intra.net
Service Name	Short name of service.
Service Description	Describe the business intent of the web service.
Service Categories	Assign Business Unit. Assign Business Area.	Jasper, IN Engineering
Binding Access Point	WSDL URL
Binding Descripiton	List of operations provided by web service.	ZERfcWsExtBackflushV2 ZERfcWsExtDiscreteBf

Sample Best Practices

• Each publisher (user) should create a provider (server) under their own account.  If more than one publisher is publishing web services on the same server, the result will be that the server name appears multiple times in search results (once for each publisher).  That's okay.

• All WSDLs are to be published to the UDDI from the TEST server.  Use the following cross reference for executing the web service in a production environment:
  
  

  Test Domain	Production Domain
  www-q15s.intra.net	www-p15s.intra.net
  www-test.intra.net	www.intra.net

• Do not duplicate the provider (server name) for each web service.  Instead assign multiple web services to a single provider.

• The service contains the functional details.  Enter a human-readable description of the service into the service description.

• The binding contains the technical details.  Enter the list of the web service operations into the binding description.

• To keep things simple, do not reference tModels in your bindings.  In my experience, this adds a great deal of complication and little to no additional value.

Enjoy.

Jeff

the obligatory initial post

WRITE: / 'hello'.