Blog Home  Home |  Breeze Home RSS 2.0 Atom 1.0 CDF  
Mick's Breeze Blogs - Biztalk/Sharepoint/... - Thursday, October 08, 2009
Things hard and not so hard....
# Thursday, October 08, 2009

Hi folks, I recently came across a tool (or enhancements to stsadm) that runs a series of rules against your farm to see if it passes some of the core requirements for upgrading to ‘a future release of SharePoint’ from WSS 3.0/MOSS 2007…so I’m guessing SP2010 :)

http://technet.microsoft.com/en-us/library/dd793607.aspx

Check it out and let me know what you think – I haven’t run it yet…looking into it.

Have fun,

Mick.

Thursday, October 08, 2009 10:09:45 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   MOSS | Admin | 2010  | 
# Sunday, October 04, 2009

My buddy Kent Weare is launching a great series of posts on pulling/pushing documents in/from SharePoint and BizTalk. Using InfoPath to beautify what hard-core developers have known for years – that thing called XML.

Kent’s just rolling up his sleeves and getting cracking - http://kentweare.blogspot.com/2009/10/biztalk-2009-sharepointwss-30.html

Well done Kent – looks great!

Sunday, October 04, 2009 10:15:38 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   2009 | 2010  | 

Something that I’ve come across in recent years and it concerns me more and more…long running transactions.

For example let’s take an Insurance Company implementing a Claims Process.

The way it works is:

  • Design Long Running Business Processes around BizTalk Orchestrations
    Sounds great on the surface and since BizTalk 2004, the techniques for implementing this were easier.
    Basically – the BizTalk Environment will look after ensuring state is maintained, waiting Orchestrations are managed and Correlations are in place for return messages, that may return seconds, minutes, weeks or months later.

    So in this case we’d implement a main claims process manager which is runs for the duration the claim is active in the system.

    A Claim comes in, enters the System and the Claims Process Manager initiates and we’re off and running.

    A common technique with long running processes is to forcibly suspend biztalk messages that are in error. At a later date someone looks into the BizTalk Admin Console (or via a WMI query) and ‘deals with’ the suspended messages.

    The benefit of these suspended messages is that they potentially can be resumed right where they left off and these messages are stored in the MsgBoxDB awaiting attention.

The reason why I don’t think this works:

  • Messages are immutable – meaning that while they’re in the MsgBoxDB they can’t be changed (technically we *can* changed these messages as a hack, but it’s *not supported*). So if the message is incorrect and in the overall process, we might fix the problem and resubmit that message – we can’t do this from within the MessageBox. We have to export the message out and provide some ‘resubmit to biztalk’ port (usually a file port).
  • BizTalk MessageBoxDB is keeping state of the system. In process Claims are part floating around as part of our system (we could also be a bank processing Loans etc etc). If we lose the MessageBoxDB this could spell even more trouble.
  • Also system upgrade complexity moves up that extra notch, careful planning and various considerations need to be thought out. Pending Orchestrations have to be allowed to run through to completion; hydrated messages waiting to be sent through Ports, means that those ports must stay around until these messages are dealt with… and many other.
  • Backup – despite the recent advancements in SQL Server 2008 (mirroring) we can’t take advantage of it in the BizTalk world.
    The supported Technique is to use Log Shipping – The recommended backup interval is 15 minutes so worse case your system is out 15 minutes in the case of a crash.

    This is not entirely true… on busy systems the actual log shipping process may take between 15-30 mins to backup. This means that during the time while log shipping backup is running, the system is not being backed up. So all in all your system could be running for 1hr (approx.) with no covering backup.

    This essentially is the state of your solution.

What Does Work….in my opinion.

  • Manage the State of your System in another area, such as SQL or SharePoint.
  • Where possible keep the Orchestrations short running.
  • Upgrades are simplier
  • System maintenance is simplier.
  • Provide a MSMQ or File Inbound Port for ‘Resubmission into BizTalk’.
  • Use Content Based Routing to establish mutually exclusive processes.

Food for thought folks, from what I’ve worked on and noticed out in the field.

Mick.

Sunday, October 04, 2009 10:05:03 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [3]   2009 | 2010 | Tips  | 
# Saturday, October 03, 2009

Well – October is always a special month for me…I’ve got family birthdays and my MVP Award is up for renomination. You basically keep getting assessed for the work done in the past year.

Keeps you on your toes and makes sure that complacency doesn’t creep in :-)

I’m happy to say I’m back for another year!!! Whoo hoo! It’s really you guys – the community that make my efforts possible. As long as you need them, I’ll do my best to help.

Bring on 2009/2010 – there should be some great advancements in our technology worlds, more agile, more cloud based and more accessible.
(‘Integration should just work’ – that’s the theory)

MVP Logo - Horizontal

Saturday, October 03, 2009 9:52:41 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   2009 | General | Other  | 
# Sunday, September 27, 2009

Well folks after my last tutorial, Finally Connected OCS to Trixbox I’m getting more and more questions about the OCS side of things…so I thought I’d expand on our OCS 2007 R2 side of the setup.

So the internal setup looks a little like this:

image

So here our IP:Z = 10.1.1.30 which makes sense when looking at the OCS machines from Trixbox as follows:

image_12[1]

Note the 10.1.1.30 or IP:Z in the hosts list here from Trixbox. In short – as far as OCS is concerned when Chatterphone gets a request (from either internal or external) it *has* to have all the knowledge to work out where to route the call.

So don’t forget that OCS embeds a VOIP phone details into User Accounts within AD – viewing the user class object will give you the right details. I wrote a webservice that will display the user’s phone numbers etc.

I also wrote a quick WebService to pull out phone and sip address details from AD from a search string. So if you supply part of a phone number, it gives you the users, and if you have a sip address, it give you the phone number. (I was going to use it for a lookup from Trixbox cause from OCS Communicator, I couldn’t get the invite another person to the conf call via phone working – it was sending an invalid CallerID out to our PSTN provider)

Download File - OcsHelperService

(source code included – as is, for a guide :)

Example calls:
I’ve installed it onto a site called ‘ocsservices.office.breeze.net’ and you can run it as follows:

  1. Lookup a Phone Number from SIP Address
    1. http://<webServer>/OcsHelperService/Lookup.svc/Process?action=getphone&caller=<sip address – minus ‘ sip:’> e.g. mickb@acme.com
  2. image
  3. Lookup a SIP Address from a Phone Number
    1. http://<webServer>OcsHelperService/Lookup.svc/Process?action=getaddr&caller=<start of a user’s voip number>
  4. image

Let’s start

Learning – What in the World is OCS doing?

Setup meaningful logging to try and work out what Trixbox<->OCS is doing = MediationServer

  1. From the OCS Management Tool – setup a New Debug Session
  2. image
  3. From the OCS 2007 R2 Logging Tool – log S4 and the Mediation Server settings.
  4. image
  5. Then click Start Logging and you should be on your way to recording what OCS is doing in response to Trixbox. This helps you find out *exactly* what OCS is responding with. Calls, “No Service" etc.
  6. Go through and run through a test session of what you’re wanting to try out. e.g. incoming call or outgoing call.
  7. Click Stop Logging and click Analyze Log Files
  8. image
  9. The OCS 2007 R2 SDK tool – snooper should come to the rescue here and display a detailed log of what happened. Colour coded and see what what going on.
  10. Here’s a sample for an outgoing call:
  11. image
  12. What’s more interesting is an incoming call:
  13. In this particular call – I rang my OCS number and hung up after 2 rings. The conversation is pretty detailed in terms of what you see with SIP. i.e. Seeing this is the MediationServer there should be something like SIP INVITE->Trixbox->SIP INVITE->OCS Mediation (Chatterphone)->OCS Server.
    You’ll notice these packets are like IP4 routing packets, with headers possibly changing, but you should be able to make out your dialled number in there.
    1. image

This is your handy weapon for OCS land – if communication isn’t getting through, then check all the IP details.

Incoming calls to OCS

  1. Users are generally identified as +<country code><area code><number>
  2. If when making an External Call in, make sure in the above logs the number coming in is in the right format. i.e. +612……….@acme.com
  3. What does a User Look Like
    1. Firstly they belong to a Location (the Location Name also has implications within ExchangeUM if you use it for Voice Mail), looking at the location code I just have it stock standard as follows:
    2. image
    3. Finally let’s look at what a user like myself looks like from the OCS Admin Tool. (In my case Enterprise Pools->BreezePool1->Users)
    4. image

Hopefully this has helped a little more in working out what is going on in your OCS world(s).

Between the logging here and the ‘Asterisk –r’ option in a console app on Trixbox, you should be getting a better picture. Because many setups can be very different, looking down here at the ‘packet’ level is really the only way to go in resolving these.

(Another handy option is to turn on Event Logging in OCS Communicator, which gives some great info from a client perspective as well :)

Good luck. :-)

Mick.

Sunday, September 27, 2009 9:15:46 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   OCS  | 
# Friday, September 25, 2009

I woke up on Wednesday morning to a thick soup blanket of red.

No buildings, no cliffs, no grass…just Red. (We’d been teleported to Mars I thought)

Pretty amazing stuff, here’s some piccies that capture the moment :)

1
2
3

Friday, September 25, 2009 6:20:26 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   General  | 
# Tuesday, September 22, 2009

I thought I’d share a few interesting SAP tales.

I’ve been working on a project lately of integrating with not 1 SAP Server, but 2 and the 2nd one is across the seas accessible via a SAP Router (which is similar to Proxy Servers for the internet). I’ve got to thank Rohit Singh (MS) and his team for some great feedback, as well as Scotty and Kent Weare whom were helping me to nut out where half these settings go.

Specifically I needed BTS to be a ‘remote RFC server’ for the two SAP Servers.

What does a Router string look like I hear you ask - “/H/devapp1/S/3300/H/acmesaprouter.acme/S/3300/H/sapdb01.acme”. Something like that, and the user’s type this into the SAP Client UI to connect…my chances of being able to ‘stick’ this somewhere in the BizTalk world was diminishing.

So I had to get my BizTalk box to talk through the ‘SAP Router’ out with the right credentials to another SAP Server 1200KMs away…”good luck” little adapter I thought. ("good luck” Mick I though too)

Here’s the low down:

  1. Use a saprfc.ini file – scarce documentation, but do able.
  2. Set a RFC_INI System Environment variable.
  3. Turn on Rfc Tracing
  4. Get on well with the SAP teams.
  5. Get on well with the SAP teams…oh I mentioned that one already.

Here’s how you do it – after you’ve installed and setup the prereqs for the SAP Adapter (don’t forget to add the SAP Adapter property schema to BizTalk)

Starting out:

- I jumped in and used the 'Consume Service Adapter' Wizard to work out connection details and look at the IDOCs schemas.

The problem is - as time goes by, you want to see debugging and other details to tweak as trying to establish a connection. The Receive Location (WCF-Custom, sapBinding) SAP URI get's horribly long.

 

I was happy to put up with this when I got the first connection to the SAP Server1 (local).

 

This *didn't* work for SAP Server2(remote) - trust me, it's a square peg in a round hole.

 

Using SAPRFC.INI :(generally the MS Docs will get you started, but I found they had incomplete settings so I had to go elsewhere - a Siebel->SAP 2001 document served the purpose)

  1. Create a System Environment Variable called RFC_INI  and point it to where you want your saprfc.ini file to live.
    e.g. SET RFC_INI=d:\BizTalk_Dev\SAP\saprfc.ini
    (the MS documentation doesn't say *exactly* where to put the saprfc.ini - I tried it in the bts folder, windir...many places)
  2. Set the Receive Location to use the saprfc.ini - e.g. sap://client=110;lang=en;@D/SAPSERVER?LISTENERDEST=BTS_INBOUND&RfcTraceSdk=true
  3. Using the SAPRFC.INI file

Sample SAPRFC.INI - for local SAP connection

DEST=SAPSERVER
TYPE=A
ASHOST=DEVAPP1
GWHOST=DEVDB1
GWSERV=sapgw00
SYSNR=00
RFC_TRACE=0
ABAP_DEBUG=0
USE_SAPGUI=0

DEST=BTS_INBOUND
TYPE=R
GWHOST=DEVDB1
GWSERV=sapgw00
PROGID=BizTalkDev_Inbound  (<-- this is allocated from SAP)
SYSNR=00
RFC_TRACE=0
ABAP_DEBUG=0
USE_SAPGUI=0

Connecting to a SAP Server via a SAP Router String - sample saprfc.ini
e.g. router string -/H/devapp1/S/3300/H/acmesaprouter.acme/S/3300/H/sapdb01.acme

ListenerURI (BTS Receive Location) = sap://client=110;lang=en;@D/ACMESAP?LISTENERDEST=ACMESAP_INBOUND&RfcTraceSdk=true

DEST=ACMESAP
TYPE=A
ASHOST=/H/devapp1/S/3300/H/acmesaprouter.acme/S/3300/H/sapdb01.acme
GWHOST/H/devapp1/S/3300/H/acmesaprouter.acme/S/3300/H/sapdb01.acme

GWSERV=sapgw00
SYSNR=00
RFC_TRACE=0
ABAP_DEBUG=0

DEST=ACMESAP_INBOUND
TYPE=R
GWSERV=sapgw00
GWHOST=/H/devapp1/S/3300/H/acmesaprouter.acme/S/3300/H/sapdb01.acme
PROGID=BizTalkDev2_Inbound
SYSNR=00
RFC_TRACE=0
ABAP_DEBUG=0

 

 

HTH folks and saves you guys some time - :)

Tuesday, September 22, 2009 9:42:18 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [2]   2009 | BizTalk Adapter Pack | SAP  | 
# Sunday, September 20, 2009

Hi folks, came across a great article that talks about WebServices(WCF Services) and Security.

The most common starting point in improving security, is to use TLS (Transport Layer Security of which SSL is a subset). I once spent 9 months working out digital signatures and passing several documents through out of band of envelopes…long story.

There’s a whole bunch of How-To’s also – very good!

With over 26000 downloads since August 1, I think this is a much needed area.
Well done guys – big congrats for your efforts.

Enjoy -

http://wcfsecurityguide.codeplex.com/

---- snip ----

SecurityLogo.jpg patterns & practices Improving Web Services Security - Now Released

Welcome to the patterns & practices Improving Web Services Security: Scenarios and Implementation Guidance for WCF project site! This guide shows you how to make the most of WCF (Windows Communication Foundation). With end-to-end application scenarios, it shows you how to design and implement authentication and authorization in WCF. Learn how to improve the security of your WCF services through prescriptive guidance including guidelines, Q&A, practices at a glance, and step-by-step how tos. It's a collaborative effort between patterns & practices, WCF team members, and industry experts. This guide is related to our WCF Security Guidance Project.
Parts
Part I, "Security Fundamentals for Web Services"
Part II, "Fundamentals of WCF Security"
Part III, "Intranet Application Scenarios"
Part IV, "Internet Application Scenarios"
Forewords
Chapters
Part I, Security Fundamentals for Web Services
Part II, Fundamentals of WCF Security
Part III - Intranet Application Scenarios
Part IV - Internet Application Scenarios

Checklist
Sunday, September 20, 2009 12:28:13 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   BizTalk | 2009 | Insights  | 
# Saturday, September 19, 2009

Like me you may have received this lately – it was all working before (and especially on the developers machine :-) .

It turns out the VS2008 loves to update a registry key post installation, any sort of new VS.NET version, e.g. VS.NET Test tools etc, will overwrite this key.

BTS specific information is wiped away…..fortunately we set the registry key back as follows:

http://blogs.msdn.com/biztalkcrt/archive/2009/08/21/visual-studio-2008-fails-to-create-open-biztalk-projects.aspx
(x86 and x64 scenarios)

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Projects\{FAE04EC0-301F-11d3-BF4B-00C04F79EFBC}]

"PossibleProjectExtensions"="csproj"   - Original VS install reg value. "PossibleProjectExtensions"="csproj;btproj" - Post Biztalk installation reg value

Saturday, September 19, 2009 8:58:53 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [2]   2009  | 
# Friday, September 11, 2009

Hi guys, thought I’d let you know about the rfid operations guide Microsoft recently released.

Covers things like HA, RFID Mobile and best practices… yours truly was one of the authors so I’m happy to take any feedback you’ve got.

Enjoy – here’s a snippet of what to expect.

Welcome to the first edition of the Microsoft® BizTalk® Server RFID Operations Guide. We created this guide to be a valuable resource for anyone involved in the implementation and administration of a BizTalk Server RFID solution.

To download a copy of this guide in .chm or .docx form, go to http://go.microsoft.com/fwlink/?LinkId=158724.

  Which Versions of BizTalk Server RFID Does the Guide Cover?

This guide is primarily for the BizTalk Server RFID product that is released as part of Microsoft BizTalk Server 2009. Even though most of the guidance applies to BizTalk Server RFID that was released as part of BizTalk Server 2006 R2, the guide uses the new platform changes wherever applicable.

  What’s in It?

This document applies to the operational readiness phase in the solution life cycle management of the project. The operational readiness phase precedes deployment to production. It consists of a set of tasks for ensuring a stable operating environment. It is targeted toward system administrators responsible for BizTalk Server RFID (server computers and RFID devices), DBAs responsible for the SQL servers used by BizTalk Server RFID, and developers involved with maintaining the infrastructure and solution. This document assumes that the BizTalk Server RFID solution has already been validated in a Pilot stage and is prepared for deployment to production.

Key portions of this guide are new; however, a considerable portion consists of documentation taken from BizTalk Server RFID Help, white papers, Knowledge Base articles, and other sources. It has been reviewed and evaluated by experts from the community of BizTalk Server IT professionals and members of the product development team, whom we gratefully acknowledge at the end of this topic. We believe that the information presented here will help BizTalk Server RFID users solve—and above all, avoid—many of the common problems that can occur while deploying and maintaining a BizTalk Server RFID installation.

  Interesting! Where Do I Start?

We organized the guide according to the functional aspects of planning, deploying, and managing a BizTalk Server RFID installation. You can therefore read it according to these functional aspects. If you are performing the following tasks, you can start with the related sections:

  • Evaluating operational readiness. If you are focused on assessing and evaluating the operational readiness of a BizTalk Server RFID deployment, then start by reading the Operations Checklists section.
  • Becoming operationally ready. To ensure that your BizTalk Server RFID infrastructure and applications become operationally ready, refer to the Planning the Environment for BizTalk Server RFID section.
  • Managing the operational environment. Most of the topics in this operations guide assist you in managing and maintaining an operational BizTalk Server RFID environment. You will find best practices, key concepts, and procedures for maintaining an operational environment in Managing BizTalk Server RFID and Monitoring BizTalk Server RFID.

Author: Rama Ramani (Microsoft)

Editor: Mary Browning (Microsoft)

Contributors

  • Mark Simms (Microsoft)
  • Rohan Makhija (Microsoft)
  • Ravi Vankamamidi (S3Edge)
  • Clint Tennill (Xterprise)
  • Damir Dobric, Andreas Erben (daenet)
  • Mick Badran (Breeze, BizTalk Server MVP)

Reviewers

  • Petr Kratochvil (Microsoft)
  • Ewan Fairweather (Microsoft)
  • Quoc Bui (Microsoft)
  • Douglas Trimble (The Boeing Company)
  • Robert Auston (Vail Resorts Management Company)
  • Luke Rennells (Bank of America N.A.)

Microsoft BizTalk Server 2009 RFID Operations Guide

Friday, September 11, 2009 9:56:50 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   2009 | RFID | Tips | Training  | 

At Teched this year I thought I’d catch up on a couple of exams…always lots to do (still didn’t do all of them) but I discovered a little tool on the MCP site – logo builder.
(I’m sure it’s been there for years :)

MCAD MCSD MCT Mick_MCTS

Notice the different colours – don’t know how that happened, but maybe I’ll plaster them up next to my ‘learn to swim’ and ‘tread water for 2mins’ certs.

Have a great weekend all – and hopefully see you sometime soon.

Mick.

Friday, September 11, 2009 9:41:23 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   General  | 
# Thursday, September 10, 2009

Last night we had an exam cram, where keen and interested delegates bunkered down and got their neurons firing.

I went through this exam with them giving them tips and sharing my general SharePoint knowledge around this.

Today – the good news was that I passed three delegates whom took the exam *today* and all passed!!! Well done guys!

Here’s the ppt deck that I used – enjoy and well done all!

70-630 MCTS- Microsoft Office SharePoint Server 2007- Mick Badran

Thursday, September 10, 2009 11:12:42 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   Events | TechEd | 2009 | Training  | 

We’re in the thick of TechEd 2009 here in Australia on the Gold Coast (tough place to have a conference ;) Sun, sand and a beach that stretches for miles 1 block away)

Big thanks to those of you that attended my session – great turn out and all my demos worked like a charm…that doesn’t happen every day :)

Here’s the powerpoints and demo files:

SOA314 BizTalk RFID Mobile - Mick Badran

PowerPoints  -


Thursday, September 10, 2009 10:50:01 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0]   2009 | RFID | Events | TechEd | 2009  | 
Copyright © 2010 Breeze Training. All rights reserved.