Things hard and not so hard.... RSS 2.0
# Thursday, October 22, 2009

Grab a look at the SDK – here - http://msdn.microsoft.com/en-us/library/dd776256.aspx and interestingly the BDC (now – Business Data Connectors) and BCS (Business Connectivity Services) are the enhanced former 2007 BDC.

BCS = http://msdn.microsoft.com/en-us/library/ee556826(office.14).aspx

I’ve got lots to talk about and show but where to start….maybe “once there was a developer…” :-)

Stay tuned.

Mick.

Thursday, October 22, 2009 10:20:47 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
MOSS | Admin | 2010
# Monday, October 19, 2009

Whilst on my travels last week I also ran into Oleg Lofman (MCS SharePoint Consultant) whom amongst other things (showed me a great travel game - http://www.travelpod.com/traveler-iq?ba96=7587) pointed me towards a tool called WIM2VHD.

Basically this tool allows you to go straight from a WIM file to VHD!! You can even specify an Answer file also. So no need to mount the ISO, go through the bootloader and copy all the files needed, then expand etc etc as part of the setup.

So seeing that Windows 7/Server 2008 R2 has a bunch of WIMs under the \Sources folder, you can simply go there and take your pick as to how extensive you want the base OS to be : Core…or something more!

Check it out:

http://code.msdn.microsoft.com/wim2vhd

As you can see below, it’s a pretty extensive and detailed tool: (you can even apply hotfixes to the VHD during this process)

--- snip from the above page ---

Usage

Usage: WIM2VHD.WSF /wim:<wimPath> /sku:<sku>
[/vhd:<vhdPath>] [/size:<vhdSizeInMb>] [/disktype:<dynamic|fixed>]
[/unattend:<unattendXmlPath>] [/qfe:<qfe1,...,qfeN>]
[/ref:<ref1,...,refN] [/dbg:<args>] [/copylocal:<localFolder>]
[/passthru:<physicalDrive>] [/signdisk:<true|false>]
[/mergefolder:<folderToMerge>]
 
Required parameters:
 
  /wim:<wimPath>
 
    The path of the WIM file to use when creating the VHD.  For example:
    X:\sources\install.wim
 
    Where X: is the drive letter of your DVD ROM drive.
 
  /sku:<skuName>|<skuIndex>
 
    The SKU within the WIM to use when creating the VHD (e.g. "ServerStandard",
    "ServerDatacenterCore", "2", etc.).  This value can either be passed as a
    SKU name (typically the easiest method) or as a SKU index (which requires
    you to have manually inspected the WIM with a tool like IMAGEX.EXE).
 
Optional parameters:
 
  /vhd:<vhdPath>
 
    The path and name of the VHD to be created.  If a file with this name
    already exists, it will be overwritten.  If no VHD is specified, a VHD will
    be created in the current folder with a name in the following format:
    <Major>.<Minor>.<Build>.<Rev>.<Arch>.<Branch>.<Timestamp>.<SKU>.<Lang>.vhd
    ex:
       6.1.7100.0.x86fre.winmain_win7rc.090421-1700.Ultimate.en-us.vhd
 
    NOTE: If the language cannot be determined from the WIM, no <Lang> block
    will be included in the VHD name.
 
  /size:<vhdSizeInMb>
 
    For Fixed disks, this is the size in MB of the VHD that will be created.
    For Dynamic disks, this is the maximum size in MB that the VHD can grow to
    as additional space is required.
    If unspecified, a default value of 40960 MB (40 GB) will be used.
 
  /disktype:<Dynamic|Fixed>
 
    Specifies what kind of VHD should be created: Dynamic or Fixed.
    A Fixed disk allocates all of the necessary disk space for the VHD upon
    creation.  A Dynamic disk only allocates the space required by files in
    the VHD at any given time, and will grow as more space is required.
    The default value is Dynamic.
 
  /unattend:<unattendXmlPath>
 
    The path to an unattend.xml file that will be used to automate the OOBE
    portion of Windows setup the first time the VHD is booted.
 
  /qfe:<qfe1,...,qfeN>
 
    A comma-separated list of QFEs to apply to the VHD after the WIM is
    applied.  QFEs must be in the .MSU file format, which is the default
    QFE format for Windows 7.  They can also be provided in a .CAB format
    if you'd prefer to extract the .CABs from the .MSU files.
 
    To extract a CAB from an .MSU, use the following command:
 
    expand -f:win*.cab <.MSU file> <location to extract to>
 
  /ref:<ref1,...,refN>
 
    A comma-separated list of WIM pieces to apply to the VHD.
    A "WIM piece" is the result of a Split WIM, and typically has a .SWM
    file extension.  The first piece of the Split WIM should be specified with
    the /WIM switch. Subsequent pieces should be specified with /REF.
      ex: WIM2VHD.WSF /WIM:C:\split.swm /REF:C:\split2.swm,c:\split3.swm
 
    See IMAGEX.EXE /SPLIT /? for more information.
 
  /dbg:<protocol>,<port/channel/target>[,<baudrate>]
 
    Configures debugging in the OS on the VHD.
    examples:
      /dbg:serial,1,115200 - configures serial debugging on COM1 at 115200bps
      /dbg:1394,10 - configures 1394 debugging on channel 10
      /dbg:usb,debugging - configures USB debugging with the target DEBUGGING
 
  /copylocal:<localFolder>
 
    Copies all of the files necessary to run WIM2VHD.WSF to localFolder,
    eliminating the need to install the Windows AIK or OPK.  This does not
    include any WIM files, just the binaries that WIM2VHD.WSF depends on.
    After this operating completes, run WIM2VHD.WSF from localFolder.
    If this switch is specified, no VHD will be created.
 
  /passthru:<physicalDrive>
 
    Applies the WIM directly to the specified drive and makes it bootable.
    NOTE: The partition on the disk must be marked as ACTIVE in order to boot
    successfully. This action is NOT performed by WIM2VHD.WSF.
 
  /signdisk:<true|false>
 
    Specifies whether or not WIM2VHD.WSF should leave a signature on the VHD
    that indicates what version of WIM2VHD.WSF created the VHD, and the date
    of creation.  The signature will be located at <VHD>:\Windows\WIM2VHD.TXT.
    The default value is "true".
 
  /mergefolder:<folderToMerge>
 
    Copies the contents of folderToMerge to the root directory of the VHD.
    This includes all subfiles and subfolders.  Any files that already exist on
    the VHD will be overwritten.


 

 

This will certainly make my life easier when it comes to building VMs!!! Thanks Oleg for the tip.

Monday, October 19, 2009 10:24:16 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
Tips | WinPE

Last week I met up with Leonid (MCS SharePoint consultant) whom has a great upfront and practical view on life. Funny guy.

He mentioned to me about a SharePoint Faceted Search – which is a series of Search Web Parts that drill into the Search Index and return metadata tags, content types and a bunch of other stuff to give you accurate search results grouped by Author, Content Type, etc. (what ever you want)

Add them to the search results page of your SharePoint Search and you’re away. The webparts examine the Query String and have a bunch of customisations that allow you to tweak it just the way you like.

Great work Leonid!!!! (he’s a very clever guy – SharePoint Search is one of his passions…Red Wine is the other :) )
You can contact him via e.mail on: xsearch a.t. microsoft dot com

Standard View – notice the red regions, categories with the exact number of results. Where std. search says “..about 512 results”

image

Adding a Couple of Categories – and looking at Content Type Search.

image

Here I clicked on Author – Mick Badran and a Content Type of ‘Word’. You can see how the ‘advanced search’ is being visually built for me.

The best thing I like about all of this is that the RHS Web Part is totally customisable. The results all come from an XML File (property of the webpart) that you can customise – we can have icons, map different words/terms for things like ‘Word’ as a content type.
You can even add/remove your own.

The webpart has collapsible sections to it (you can even set how many items you want visible when collapse in the section!) and the collapsing/expanding is driven off Javascript calls back to the Server, so no round tripping.

Simply download, install the Solution, Activate the Feature for your Site Collection and add the Web Parts to your page. Easy as that to get started.

Brilliant – absolutely Brilliant (I’ve already had some of our users emailing me to say how easy it is)

Grab them here from CodePlex - http://www.codeplex.com/Wikipage?ProjectName=FacetedSearch

---- snip from the CodePlex Main Page ----

Project Description
MOSS Faceted Search is a set of web parts that provide intuitive way to refine search results by category (facet).
The facets are implemented using SharePoint API and stored within native SharePoint METADATA store. The solution demonstrates following key features:

  • Grouping search results by facet
  • Displaying a total number of hits per facet value
  • Refining search results by facet value
  • Update of the facet menu based on refined search criteria
  • Displaying of the search criteria in a Bread Crumbs
  • Ability to exclude the chosen facet from the search criteria
  • Flexibility of the Faceted search configuration and its consistency with MOSS administration
Monday, October 19, 2009 10:13:29 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
MOSS | Admin | 2010

With the SharePoint conference starting this week I’m sure there’ll be some great messaging coming out.

When we’re given the green light I’ll talk about the many fantastic improvements on the way to a SharePoint site near you!!!

Stay tuned….

Monday, October 19, 2009 5:57:39 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
MOSS | Admin | Guides | 2010
# Saturday, October 10, 2009

While on a current project and having a need to tweak (as always) how well BTS is processing these receives, I came across a Perf document on BTS 2009 Receiving.

This document below deals mainly with netTCP receive locations – oneway ports + oneway Orchs.

Enjoy.

------

BizTalk Server 2009 Performance Optimization Guide

Brief Description

The BizTalk Server 2009 Performance Optimization Guide provides prescriptive guidance on the best practices and techniques that should be followed to optimize BizTalk Server performance.

http://www.microsoft.com/downloads/details.aspx?FamilyID=24660797-0C8F-4687-9D5F-B76D99B37EC2&displaylang=en

Saturday, October 10, 2009 3:23:52 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
BizTalk | 2009

 image Service Pack 1 Beta


The BizTalk team are pleased to announce the availability of the beta release of Service Pack 1 for BizTalk Server 2006 R2. We would like to offer you the opportunity to download this early preview of the Service Pack and encourage you to test it out and let us have any feedback before we release it to the BizTalk community.

Microsoft BizTalk Server 2006 R2 Service Pack 1 (SP1) is an update for BizTalk Server 2006 R2.  It includes fixes to issues that have been reported through our customer feedback platforms, as well as internally discovered issues. To see a listing of the customer-reported issues that are fixed in this service pack, go to http://go.microsoft.com/fwlink/?LinkId=164985.  For a description of some of the other updates included in this service pack, see What's new in BizTalk Server 2006 R2 SP1 (http://go.microsoft.com/fwlink/?LinkId=163958). 

A guide for this service pack is also available on the download page.  This guide contains important information to read before you install SP1.  It also provides installation instructions and a section on troubleshooting installation problems. Finally, it contains a section on known issues in this service pack release.

The service pack can be downloaded from here and any feedback or issues you encounter can be reported here

Thank you in advance!

Regards

BizTalk Product Group

Saturday, October 10, 2009 10:43:04 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
BizTalk | 2006 R2

This whitepaper is typically centered around the BTS SharePoint Adapter and WSS V3.0/MOSS 2007.
(I’ll be posting details on SharePoint 2010 integration shortly… :) )

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dd4e843d-2121-4016-8391-d763d0ff0a08

BizTalk + SharePoint: 1+1=3: Integration Best Practices

Brief Description

The integration of Microsoft BizTalk Server 2009 and Microsoft Office SharePoint 2007 brings a whole new set of capabilities to end users. Microsoft Office SharePoint Server gives BizTalk Server a “face,” providing human workflow features and dashboard functionality.

Saturday, October 10, 2009 10:35:04 AM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
BizTalk | 2009 | MOSS | 2010
# 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
Archive
<October 2009>
SunMonTueWedThuFriSat
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
Blogroll
 AppFabric CAT
AppFabric Windows Server Customer Advisory Team - New Blog.
[Feed] BizTalk 2006 - Windows SharePoint Services adapter
BizTalk 2006 Sharepoint adapter!!
 Breeze SharePoint 2010 Bootcamp
Breeze SharePoint 2010 Bootcamp
[Feed] BTS 2006 R2/EDI
[Feed] Chris Vidotto (MS BTS Legend)
Needs no intro....
 Mark Daunt
BTS/SPS/.NET GURU!!!
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014
Breeze
Sign In
Statistics
Total Posts: 606
This Year: 10
This Month: 3
This Week: 0
Comments: 270
All Content © 2014, Breeze