In this Blog a Request/Reply Map is created to verify the Event based map which can send and receive data. This can be done a number of ways but Postman is more commonly used utility that can be used for this purpose. Login to app.scribesoft.com and select the Organization as CloudFronts Technologies LLP. To Create a new Solution click on the + Button and Select Integration Event Now Rename the Solution and in the Maps section, click on the three ellipsis and select Create Request/Reply Map to create a new Map. Now Rename the Map and Add Connector. You can Create a new Connector or select any connector which is already created. Create a Map as shown below. In Wait for Request Block, click on Request and add field names as desired and Click on Validate and then OK. In Create Block, in General Tab and add the entity name in which you want to integrate. In Fields Tab, map the important fields and click on OK. In Build Reply Block, in the Fields tab drag and drop the fields from Results section to the Target Connection side and the click OK. Once the Map is created then Click on Apply and OK. Again open the map and copy the Endpoint URL. Now in Postman click on + icon and Add a request. Select POST and paste the Endpoint URL, then in Authentication tab select No Auth. In the Headers tab, enter the Key and the value as shown In the Body tab, select raw and select JSON, then type the JSON Format and enter the field and value as desired. Click on Send. You will get this as result in the Body section. In Tibco, in the execution history you can see the process is completed successfully. In CRM, you can now see the Record is created.

Introduction: While migrating Cases, the migration of activities of type ‘Case Resolution’ is necessary. However, the complexity in migrating this increases due to the fact that when the status of a case is updated, a blank case resolution activity is created automatically by the system. This system-generated case resolution needs to be deleted as this would result in each case having two case resolution activities after migration – one system-generated and one with the correct migrated data from the source. Solution: To tackle this issue, one must follow the following steps during migration: 1. Send all Cases (no matter what the status in the source environment) to the target with their status as ‘Open’. 2. Send all related activities to the target environment. 3. Update the case status in the target environment to its status as in the source environment. 4. For cases with status ‘Resolved’, a system-generated case resolution activity will be created. 5. In your case resolution migration map, first add a step to delete the existing case resolution in the target and then insert the case resolution from the source environment. 6. Now your case with status ‘Resolved’ will have only one case resolution and that will be the one migrated from the source environment with the correct data. Conclusion: Above steps shed some light on how to preserve the integrity of case resolution activity data in your target environment during data migration.

Error: You may face an issue in Scribe where the Scribe Services are not starting or are stuck in the Start state and an error pops up after a while as follows: Without the Scribe Services we cannot use either the Console or the Workbench to develop integration maps. Following is the Solution to resolve the above issue. Solution: Right click on the Scribe AdminServer service and select Properties. Select the Log On Tab and click on This account. Browse and select that Windows account which has been setup as the Scribe Service Account. This is generally the same account with which Scribe has been installed on your machine. Follow steps 1, 2 and 3 for the remaining Scribe services as well. Restart your machine. Conclusion: After restarting you should be able to start your services. Make sure you start your Scribe services in a sequential order and you should be able to open your Scribe Console now.

Introduction: Recently, we encountered an error while integrating Sales Orders from Salesforce to Microsoft Dynamics NAV via Scribe displaying the following error message. Error Details: “The Sales Header Extension does not exist. Identification fields and values: Document Type=’Quote’, No=’ ‘ ” Reason for the error: Upon further debugging, we found that a field in the Target NAV environment was throwing the error when Scribe was trying to input data into it. Solution: The configuration of the field in the Target NAV environment needs to be changed so that it can populate data being integrated by Scribe. This will allow Scribe to integrate the record successfully!

Issue: While trying to integrate records from SFDC to Dynamics NAV 2017, I faced an issue in Scribe saying “The record already exists.”. When I checked in Dynamics NAV 2017, there were no records similar to the one I was trying to integrate when the error occurred. Additionally, when I tried to create a new record in NAV, I got the same error if I filled some other field before filling out the ‘Name’ field. Solution: After some trial and error, I found that this error gets triggered when there is a record not having a value for ‘No.’ which is the Primary Key. Once I deleted this record, creating new records in NAV was no longer an issue for Scribe.

Introduction: There may arise a scenario where after creating a connection to Salesforce, a field that exists in Salesforce isn’t visible in your Scribe Insight DTS. This can happen because of multiple reasons. In this article I have listed down 3 of the most likely reasons why your SFDC field is not visible in Scribe Insight. Three Probable Reasons: Reason 1 The first reason can be that a custom field was created in your SFDC after you had created your SFDC connection in Scribe Insight. To fix this follow the steps mentioned below: Go to Connections in your DTS Select your SFDC connection Select Edit -> DTS Connection Settings -> Adapter Settings and click on Refresh Metadata. Your custom field should now be visible. Reason 2 The second reason can be that the field-level security has the visibility disabled for that field. To fix this follow the steps mentioned below: Log into SFDC classic and select Setup Go to Build -> Customize -> Object (Eg. Accounts, Asset) -> Fields Click on the field that isn’t visible in Scribe Insight and select Set Field-Level Security Make sure the field is visible for your Profile Reason 3 The third reason can be that you are just using an old API of Salesforce and that field did not exist for that version of SFDC. For example the Asset RecordTypeId field was added in the later versions of Salesforce. To fix this follow the steps mentioned below: Go to Connections Select your SFDC connection and click on Edit Select Change Connection Update the version of the Salesforce URL to the latest version that your SFDC supports

Introduction: The Variable Connector, created as part of the Scribe Labs initiative, adds a much-needed feature to TIBCO Cloud Integration i.e. to store and retrieve variables in a Scribe Map. However, keep in mind, these variables cannot be shared between maps or solutions. Steps For Installation: To begin using the connector, install it from the Scribe Marketplace. Go to Marketplace. Search for ‘Variables’. Select Scribe Labs – Variables and click ‘Install’. The Connector will install for your Organisation in a few minutes. Steps To Create A Variable Connection: From the ‘More’ dropdown menu, click on ‘Connections’. Click on the plus sign (+) on the right of the page to add a new connection. Select your Connector Type, input the name of the variable connection and select the Agent. Click OK. Steps to use in a Map: Add the variable connection to your map. To store a value in the variable, select the Upsert block. In the General Tab, select the data type of the variable you want to store from the Entity dropdown menu. In the Fields Tab, input the name of the variable in the ‘name’ field and the data you want to store in the variable in the ‘val’ field. Click OK. To retrieve a variable, use the Lookup Block from the Variable Connection. Select the data type of the variable in the Entity tab. In the Lookup Criteria tab, lookup the name of the variable you had set. Select the ‘val’ field in the Field List tab. Click OK. You can now use the data stored in the ‘val’ field of the variable in your map. Conclusion: I hope this helps understand the usage of the Variable Connector in TIBCO Cloud Integration. This feature is very useful when one needs the functionality of a variable while using TIBCO Cloud Integration.

Issue: Microsoft Message Queuing (MSMQ) service running on Server might be unable to receive messages. Therefore, messages stay in “Waiting to connect” state in the outgoing queue of the sending computers. Cause: Issue occurs on 2 scenarios- During computer start, MSMQ service tries to bind to machine IP for listening which is still not acquired by DHCP. This might happen when DHCP takes some time acquiring IP due to any network latency or service start timing between DHCP and MSMQ. In this case MSMQ starts listening to the loopback address i.e. 127.0.0.1. DHCP acquired IP correctly and MSMQ listening on that IP as well. However, at some later point, DHCP IP renewal happens and now machine IP is different from the last one. In this case MSMQ is still listening on the older IP. So, when a new message comes for any old IP, it is never seen by MSMQ service. Verify Scenario: In Command Prompt, type following command and check the result netstat –abno | findstr 1801 If the system is facing this problem, output resembles the following in first scenario: TCP 127.0.0.1:1801 0.0.0.0:0 LISTENING xxxx TCP [::1]:1801 [::]:0 LISTENING xxxx Output resembles the following in second scenario: TCP y.y.y.y:1801 0.0.0.0:0 LISTENING xxxx where, y.y.y.y is the IP address which MSMQ port is listening to but this is different from the IP it should listen to. Resolution: Restart Message Queuing Service If Point 1 don’t resolve the issue, Install this Metadata hotfix.  https://support.microsoft.com/en-us/hotfix/kbhotfix?kbnum=2554746&kbln=en-US

Introduction: In this blog, I will detail how to migrate Activity Parties of Emails from one CRM to another. In my previous blog, I outlined the first step of the Email migration process which is migrating the body of the email. Migrating the corresponding Activity Parties of an Email is the second step of this process, as the Email body now exists in the Target CRM. What are Activity Parties? Other than the Body, an Email Activity consists of: Sender: The person(s) sending the email. Recipient: The person(s) receiving the email. CC & BCC: The person(s) that are copied in the email. Owner: The person who is the owner of the email. Regarding: This generally links to an entity in CRM which pertains to the email. For example, a Case or a Project in CRM. ‘Sender’, ‘Recipient’, CC’, ‘BCC’, ‘Owner’ and ‘Regarding’ are each stored in CRM as a separate Activity Party of that email with a ‘Participation Type’ code (field name: ‘participationtypemask’) to establish the field that specific party belongs to i.e. 1 = Sender, 2= To Recipent and so on (as shown below). Generally, in an Activity Party, the person(s) are either System Users or Contacts. This is specified in the field ‘partyobjecttypecode’ as shown above. Keeping this in mind, one can lookup to these entities to obtain the corresponding GUIDs in the Target System and map it as the ‘partyid ‘. After the Activity Party is created, the owner of the Activity Party should be updated as per its owner in the Source environment. The ‘Owner’ Activity Party is automatically created by CRM as the same User as the Owner of the Email (configured when you migrate the Email Body in Step 1). The ‘Regarding’ Activity Party links to a Case/ Project and not a ‘person’, however, the same logic applies i.e. map the required GUID and its type. Migrating Activity Parties is not as complicated once understood. Unfortunately, not much is easily available online about this. I hope this blog demystified a few concepts about Activity Parties of an Email and how they can be migrated from one CRM to another. My next blog will detail how to migrate Email Attachments and update the status of an Email.

Introduction: Data migration can be a little challenging, especially when it comes to Emails. In this blog, I will outline the steps that need to be followed to successfully migrate Emails as well as important things to keep in mind during the process. Steps: There are four main steps to follow to successfully migrate an Email from Source to Target: Send the body of the Email. Send all the related Activity Parties. Send the details of the related Email Attachment(s). Update the Status of the Email. In this blog, we will be dealing with the first step i.e. creating the map in TIBCO Cloud Integration to send the Body of an Email. Migrating the body of the Email is straightforward compared to the next step but there are a few aspects to keep in mind: 1) Send the email as Open so that Activity Parties and Attachments can be migrated in the following steps. Not sending the email with an “Open” status could lead to Activity Parties and Attachments not being migrated to the corresponding email. 2) When an email is migrated, the owner of the email will be the User configured in the CRM Connection in Scribe. In order to maintain the same owner as in the Source, you can update the email with the correct owner after it is created. In the screenshot below, I am using a Lookup Table in Scribe to map the User GUID of the Target System. 3) If you want the GUID of the email to remain the same in Source and Target, do not forget to map the ‘activityid’ of the Email entity. Conclusion: I hope this blog provided some insight into the migration process for Email Activities. In the next blog ‘Email Migration from CRM v8.2 to CRM v9 using TIBCO Cloud Integration: Activity Parties‘, I will talk about migrating ‘Activity Parties’ which can be the most challenging part of Email Migration.